Ubiquitous visual computing witness

ABSTRACT

In one embodiment, an apparatus comprises a memory and a processor. The memory is to store sensor data captured by one or more sensors associated with a first device. Further, the processor comprises circuitry to: access the sensor data captured by the one or more sensors associated with the first device; determine that an incident occurred within a vicinity of the first device; identify a first collection of sensor data associated with the incident, wherein the first collection of sensor data is identified from the sensor data captured by the one or more sensors; preserve, on the memory, the first collection of sensor data associated with the incident; and notify one or more second devices of the incident, wherein the one or more second devices are located within the vicinity of the first device.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 16/004,299, filed on Jun. 8, 2018, and entitled “UBIQUITOUSVISUAL COMPUTING WITNESS”, which claims the benefit of the filing dateof U.S. Provisional Patent Application Ser. No. 62/611,536, filed onDec. 28, 2017, and entitled “VISUAL FOG,” the content of which is herebyexpressly incorporated by reference.

FIELD OF THE SPECIFICATION

This disclosure relates in general to the field of visual computing, andmore particularly, though not exclusively, to a ubiquitous visualcomputing witness.

BACKGROUND

The process of gathering facts, evidence, and/or information ofteninvolves numerous sources, such as eye witnesses, physical environments,electronic environments (e.g., surveillance systems), and so forth.Existing approaches for gathering facts and evidence, however, sufferfrom various shortcomings. In many cases, for example, it can bechallenging or impossible to even identify the respective sources ofrelevant data. Further, because existing approaches are not automated,they typically require information to be manually collected from eachindividual source. Moreover, the respective sources are often under theownership and/or control of multiple different entities, which furthercomplicates the information gathering process. Finally, whileadvancements in technology have led to widespread penetration ofnumerous types of electronic devices that could potentially be leveragedfor information gathering purposes (e.g., cameras, sensors, mobiledevices), there is no efficient mechanism for identifying electronicdevices with relevant information and collecting information from thosedevices.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is best understood from the following detaileddescription when read with the accompanying figures. It is emphasizedthat, in accordance with the standard practice in the industry, variousfeatures are not necessarily drawn to scale, and are used forillustration purposes only. Where a scale is shown, explicitly orimplicitly, it provides only one illustrative example. In otherembodiments, the dimensions of the various features may be arbitrarilyincreased or reduced for clarity of discussion.

FIG. 1 illustrates an example embodiment of a visual fog system inaccordance with certain embodiments.

FIGS. 2-5 illustrate examples of Internet-of-Things (IoT) networks andarchitectures that can be used in accordance with certain embodiments.

FIGS. 6-7 illustrate example computer architectures that can be used inaccordance with certain embodiments.

FIG. 8 illustrates an example embodiment of an architecture for visualfog nodes.

FIG. 9-12A-12B illustrate example embodiments of a visual fogarchitecture.

FIG. 13-14 illustrate example embodiments associated with a visualquestion answering (VQA) framework.

FIGS. 15-16 illustrate example embodiments of device-centric schedulingfor visual fog computing.

FIG. 17 illustrates an example embodiment of a runtime processingpipeline for a visual fog architecture.

FIG. 18 illustrates an example embodiment of a visual data storagearchitecture.

FIG. 19 illustrates an example of a vision processing pipeline thatleverages metadata for searching visual data.

FIGS. 20-21 illustrate examples of representing visual metadata using aproperty graph.

FIG. 22 illustrates an example embodiment of an analytic image formatdesigned to aid in visual data processing.

FIG. 23 illustrates a performance graph for various image formats.

FIGS. 24A-C illustrate an example embodiment of a multi-domain cascadeconvolutional neural network (CNN).

FIGS. 25A and 25B-31A and 31B illustrate the use of butterfly operationsfor a multi-domain convolutional neural network (CNN).

FIGS. 32-33 illustrate an example embodiment of a three-dimensional (3D)CNN for processing compressed visual data.

FIG. 34 illustrates an example of a pixel-domain CNN.

FIG. 35 illustrates an example of a pixel-domain visual analyticspipeline.

FIGS. 36-37 illustrate example embodiments of compressed-domain visualanalytics pipelines.

FIG. 38 illustrates a performance graph showing the precision of a CNNtrained using compressed visual data.

FIG. 39 illustrates a flowchart for an example embodiment ofcontext-aware image compression.

FIGS. 40A-C illustrate an example embodiment of a privacy-preservingdemographic identification system.

FIGS. 41-43 illustrate an example embodiment of privacy-preservingdistributed visual data processing.

FIGS. 44-46 illustrate example embodiments of self-sovereign deviceidentification for distributed computing networks.

FIG. 47 illustrates an example of device onboarding/commissioning in avisual fog network without conflict resolution.

FIGS. 48-49 illustrate example embodiments of algorithm identificationfor distributed computing using a self-sovereign blockchain.

FIGS. 50-52 illustrate example embodiments for processing traditionaland analytic image formats.

FIG. 53 illustrates a flowchart for an example embodiment ofprivacy-preserving demographics identification.

FIG. 54 illustrates a flowchart for an example embodiment ofprivacy-preserving distributed visual processing.

FIG. 55 illustrates an example use case for an automotive ubiquitouswitness.

FIG. 56 illustrates an example dataflow for a ubiquitous witness.

FIG. 57 illustrates an example use case for automotive anomaly detectionand reconstruction.

FIG. 58 illustrates an example process flow for IP-based anomalydetection and reconstruction.

FIG. 59 illustrates an example process flow for ICN-based anomalydetection and reconstruction.

FIG. 60 illustrates an example process flow of an individual node forICN-based anomaly detection and reconstruction.

FIG. 61 illustrates a flowchart for an example embodiment of aubiquitous visual computing witness.

FIG. 62 illustrates an example embodiment of a converged node router.

FIG. 63 illustrates an example network topology using converged noderouters.

EMBODIMENTS OF THE DISCLOSURE

This patent application claims the benefit of the filing date of U.S.Provisional Patent Application Ser. No. 62/611,536, filed on Dec. 28,2017, and entitled “VISUAL FOG,” the content of which is herebyexpressly incorporated by reference.

The following disclosure provides many different embodiments, orexamples, for implementing different features of the present disclosure.Specific examples of components and arrangements are described below tosimplify the present disclosure. These are, of course, merely examplesand are not intended to be limiting. Further, the present disclosure mayrepeat reference numerals and/or letters in the various examples. Thisrepetition is for the purpose of simplicity and clarity and does not initself dictate a relationship between the various embodiments and/orconfigurations discussed. Different embodiments may have differentadvantages, and no particular advantage is necessarily required of anyembodiment.

Example embodiments that may be used to implement the features andfunctionality of this disclosure will now be described with moreparticular reference to the attached FIGURES.

Visual Fog Introduction

FIG. 1 illustrates an example embodiment of a visual fog system 100 inaccordance with certain embodiments. Advancements in modern computinghave led to an increased use of computer vision technologies andlarge-scale visual computing for a variety of mainstream computingapplications. In particular, rapid deployments of cameras and othertypes of computer vision technologies have been leveraged for a varietyof visual computing applications that rely on large-scale videoanalytics and visual data processing. For example, large-scale visualcomputing can be leveraged for security and surveillance, transportation(e.g., traffic monitoring, navigation, parking, infrastructure planning,security or amber alerts), retail (e.g., customer analytics), enterpriseapplications, and so forth.

Existing approaches to large-scale visual computing, however, sufferfrom numerous limitations. In particular, existing visual computingapproaches are implemented using rigid designs that utilize resourcesinefficiently (e.g., processing, bandwidth, and storage resources) andprovide limited functionality. For example, using existing approaches,visual data is typically captured by devices at the edge of a networkand simply funneled to the cloud for processing and storage, thusrelying heavily on the cloud infrastructure. Due to the large size ofvisual data, however, this approach typically consumes significantnetwork bandwidth and requires substantial processing and storageresources in the cloud. As a result, existing approaches often sufferfrom high latency and inefficient resource utilization, and may also beinaccurate, unreliable, inflexible, and incapable of scalingefficiently.

Accordingly, this disclosure describes various embodiments of a visualfog computing system 100 for performing large-scale visual computing inan efficient and reliable manner. For example, rather than relyingexclusively or primarily on cloud resources 130 for visual computingtasks, visual fog system 100 leverages both cloud 130 and edge 110resources, which may be collectively referred to as the “fog.” In thismanner, visual fog system 100 can leverage all available “fog” resourcesto perform visual computing tasks more efficiently, thus improvingresource utilization, latency, accuracy, precision, and reliability.Moreover, as described further throughout this disclosure, visual fogsystem 100 can be implemented using a flexible design that supportsad-hoc queries and is highly scalable, thus rendering it suitable formany visual computing applications and use cases.

In the illustrated embodiment of FIG. 1, visual fog system 100 includesedge resources 110 and a plurality of associated visual sensors 120,cloud resources 130, and communication networks 150, which arerespectively discussed further below. Moreover, in various embodiments,these components of visual fog system 100 may be implemented some or allaspects of the visual computing functionality described throughout thisdisclosure in connection with the remaining FIGURES.

Edge resources 110 may include any equipment, devices, and/or componentsdeployed or connected near the “edge” of a communication network. In theillustrated embodiment, for example, edge resources 110 include end-userdevices 112 a,b (e.g., desktops, laptops, mobile devices),Internet-of-Things (IoT) devices 114, and gateways or routers 116, asdescribed further below. Edge resources 110 may communicate with eachother and/or with other remote networks and resources (e.g., cloudresources 130) through one or more communication networks 150, such aslocal area network 150 a and/or wide area network 150 b. Moreover, inthe illustrated embodiment, edge resources 110 collectively include aplurality of visual sensors 120 (e.g., cameras) for capturing visualrepresentations and data associated with their surroundings. In someembodiments, for example, certain end-user devices 112 and/or IoTdevices 114 may include one or more cameras and/or other types of visualsensors 120. Visual sensors 120 may include any type of visual oroptical sensors, such as cameras, ultraviolet (UV) sensors, laserrangefinders (e.g., light detection and ranging (LIDAR)), infrared (IR)sensors, electro-optical/infrared (EO/IR) sensors, and so forth.

End-user devices 112 may include any device that enables or facilitatesinteraction with a user in visual fog system 100, including, forexample, desktop computers, laptops, tablets, mobile phones and othermobile devices, and wearable devices (e.g., smart watches, smartglasses, headsets), among other examples.

IoT devices 114 may include any device capable of communicating and/orparticipating in an Internet-of-Things (IoT) system or network. IoTsystems may refer to new or improved ad-hoc systems and networkscomposed of a variety of different devices (e.g., IoT devices 114)interoperating and synergizing for a particular application or use case.Such ad-hoc systems are emerging as more and more products and equipmentevolve to become “smart,” meaning they are controlled or monitored bycomputer processors and are capable of communicating with other devices.For example, an IoT device 114 may include a computer processor and/orcommunication interface to allow interoperation with other components ofvisual fog system 100, such as with cloud resources 130 and/or otheredge resources 110. IoT devices 114 may be “greenfield” devices that aredeveloped with IoT capabilities from the ground-up, or “brownfield”devices that are created by integrating IoT capabilities into existinglegacy devices that were initially developed without IoT capabilities.For example, in some cases, IoT devices 114 may be built from sensorsand communication modules integrated in or attached to “things,” such asequipment, toys, tools, vehicles, living things (e.g., plants, animals,humans), and so forth. Alternatively, or additionally, certain IoTdevices 114 may rely on intermediary components, such as edge gatewaysor routers 116, to communicate with the various components of system100.

IoT devices 114 may include various types of sensors for monitoring,detecting, measuring, and generating sensor data and signals associatedwith characteristics of their environment. In some embodiments, forexample, certain IoT devices 114 may include visual sensors 120 (e.g.,cameras) for capturing visual representations and data associated withtheir surroundings. IoT devices 114 may also include other types ofsensors configured to detect characteristics such as movement, weight,physical contact, temperature, wind, noise, light, position, humidity,radiation, liquid, specific chemical compounds, battery life, wirelesssignals, computer communications, and bandwidth, among other examples.Sensors can include physical sensors (e.g., physical monitoringcomponents) and virtual sensors (e.g., software-based monitoringcomponents). IoT devices 114 may also include actuators to performvarious actions in their respective environments. For example, anactuator may be used to selectively activate certain functionality, suchas toggling the power or operation of a security system (e.g., alarm,camera, locks) or household appliance (e.g., audio system, lighting,HVAC appliances, garage doors), among other examples.

Indeed, this disclosure contemplates use of a potentially limitlessuniverse of IoT devices 114 and associated sensors/actuators. IoTdevices 114 may include, for example, any type of equipment and/ordevices associated with any type of system 100 and/or industry,including transportation (e.g., automobile, airlines), industrialmanufacturing, energy (e.g., power plants), telecommunications (e.g.,Internet, cellular, and television service providers), retail, medical(e.g., healthcare, pharmaceutical), and/or food and beverage, amongothers. In the transportation industry, for example, IoT devices 114 mayinclude equipment and devices associated with aircrafts, automobiles, orvessels, such as navigation systems, autonomous flight or drivingsystems, traffic monitoring and/or planning systems, parking systems,and/or any internal mechanical or electrical components that aremonitored by sensors (e.g., engines). IoT devices 114 may also includeequipment, devices, and/or infrastructure associated with industrialmanufacturing and production, shipping (e.g., cargo tracking),communications networks (e.g., gateways, routers, servers, cellulartowers), server farms, electrical power plants, wind farms, oil and gaspipelines, water treatment and distribution, wastewater collection andtreatment, and weather monitoring (e.g., temperature, wind, and humiditysensors), among other examples. IoT devices 114 may also include, forexample, any type of “smart” device or system, such as smartentertainment systems (e.g., televisions, audio systems, videogamesystems), smart household or office appliances (e.g.,heat-ventilation-air-conditioning (HVAC) appliances, refrigerators,washers and dryers, coffee brewers), power control systems (e.g.,automatic electricity, light, and HVAC controls), security systems(e.g., alarms, locks, cameras, motion detectors, fingerprint scanners,facial recognition systems), and other home automation systems, amongother examples. IoT devices 114 can be statically located, such asmounted on a building, wall, floor, ground, lamppost, sign, water tower,or any other fixed or static structure. IoT devices 114 can also bemobile, such as devices in vehicles or aircrafts, drones, packages(e.g., for tracking cargo), mobile devices, and wearable devices, amongother examples. Moreover, any type of edge resource 110 may also beconsidered as an IoT device 114, including end-user devices 112 and edgegateways 116, among other examples.

Edge gateways and/or routers 116 may be used to facilitate communicationto and from edge resources 110. For example, gateways 116 may providecommunication capabilities to existing legacy devices that wereinitially developed without any such capabilities (e.g., “brownfield”IoT devices 114). Gateways 116 can also be utilized to extend thegeographical reach of edge resources 110 with short-range, proprietary,or otherwise limited communication capabilities, such as IoT devices 114with Bluetooth or ZigBee communication capabilities. For example,gateways 116 can serve as intermediaries between IoT devices 114 andremote networks or services, by providing a front-haul to the IoTdevices 114 using their native communication capabilities (e.g.,Bluetooth, ZigBee), and providing a back-haul to other networks 150and/or cloud resources 130 using another wired or wireless communicationmedium (e.g., Ethernet, Wi-Fi, cellular). In some embodiments, a gateway116 may be implemented by a dedicated gateway device, or by ageneral-purpose device, such as another IoT device 114, end-user device112, or other type of edge resource 110. In some instances, gateways 116may also implement certain network management and/or applicationfunctionality (e.g., visual computing functionality, IoT application andmanagement functionality), either separately or in conjunction withother components, such as cloud resources 130 and/or other edgeresources 110.

Cloud resources 130 may include any resources or services that arehosted remotely over a network, which may otherwise be referred to as inthe “cloud.” In some embodiments, for example, cloud resources 130 maybe remotely hosted on servers in a datacenter (e.g., applicationservers, database servers). Cloud resources 130 may include anyresources, services, and/or functionality that can be utilized by or foredge resources 110, including but not limited to, visual computingapplications and services, IoT application and management services, datastorage, computational services (e.g., data analytics, searching,diagnostics and fault management), security services (e.g.,surveillance, alarms, user authentication), mapping and navigation,geolocation services, network or infrastructure management, paymentprocessing, audio and video streaming, messaging, social networking,news, and weather, among other examples.

Communication networks 150 a,b may be used to facilitate communicationbetween components of system 100. In the illustrated embodiment, forexample, edge resources 110 are connected to local area network (LAN)150 a in order to facilitate communication with each other and/or otherremote networks or resources, such as wide area network (WAN) 150 band/or cloud resources 130. In various embodiments, visual fog system100 may be implemented using any number or type of communicationnetwork(s) 150, including local area networks, wide area networks,public networks, the Internet, cellular networks, Wi-Fi networks,short-range networks (e.g., Bluetooth or ZigBee), and/or any other wiredor wireless communication networks or mediums.

In general, edge resources 110 (and in particular IoT devices 114) maygenerate an extremely large volume and variety of data. As one example,edge resources 110 with visual sensors 120 may generate large volumes ofvisual data, such as video and/or images. Edge resources 110 typicallyoffload this data to the cloud 130 for processing and/or storage. Cloudresources 130, however, may not necessarily be suited to handle therapidly growing volume, variety, and velocity of data generated by IoTdevices 114 and other edge resources 110. For example, cloud-basedprocessing may not be ideal in certain circumstances, such as processingtime-sensitive or highly confidential data, or when faced with networkbandwidth constraints, among other examples. Accordingly, in someembodiments, visual fog system 100 may leverage “edge” processing toaugment the performance and capabilities of the cloud 130 using edgeresources 110. Edge processing is an approach that involves processingcertain data at the network edge (e.g., using edge resources 110), nearwhere the data is generated, rather than simply funneling large volumesof data to the cloud for processing and storage. Certain data may stillbe sent to the cloud, as appropriate, such as for deeper analysis and/orlong-term storage. Edge processing may be used to complement theshortcomings of cloud-based processing (e.g., when cloud-basedprocessing is inefficient, ineffective, and/or unsecure), and thusimprove the handling of the growing volume, variety, and velocity ofdata generated by IoT devices 114 and/or other edge resources 110. Forexample, in some cases, processing data near its source (e.g., in thenetwork edge) rather than in the cloud may improve performance and/oravoid system failures or disasters. Edge processing may also conservenetwork bandwidth, which may be particularly beneficial when facingbandwidth constraints and/or limited network connectivity.

In some cases, the collective use of both edge 110 and cloud 130resources may be referred to as “fog” computing, as functionality of the“cloud” 130 is effectively extended by the edge resources 110, thusforming a “fog” over the network edge. Moreover, in some embodiments,devices 110 in the “fog” may connect and/or communicate with each otherusing an interconnection standard or protocol, such as the openinterconnect consortium (OIC) standard specification 1.0, released bythe Open Connectivity Foundation™ (OCF) on Dec. 23, 2015, which enablesdevices to discover and connect with each other; Thread, a networkingprotocol for Internet-of-Things (IoT) devices used in “smart” homeautomation and similar deployments, developed by an alliance oforganizations named the “Thread Group”; the optimized link state routing(OLSR) protocol; and/or the better approach to mobile ad-hoc networking(B.A.T.M.A.N.), among other examples.

Moreover, in some embodiments, fog computing may be leveraged by visualfog system 100 for large-scale visual computing applications. Forexample, in some embodiments, the components of visual fog system 100(e.g., edge resources 110, cloud resources 130) may be implemented withsome or all aspects of the visual computing functionality describedthroughout this disclosure in connection with the remaining FIGURES.

Any, all, or some of the computing devices of system 100 may be adaptedto execute any operating system, including Linux or other UNIX-basedoperating systems, Microsoft Windows, Windows Server, MacOS, Apple iOS,Google Android, or any customized and/or proprietary operating system,along with virtual machines adapted to virtualize execution of aparticular operating system.

While FIG. 1 is described as containing or being associated with aplurality of elements, not all elements illustrated within system 100 ofFIG. 1 may be utilized in each alternative implementation of the presentdisclosure. Additionally, one or more of the elements described inconnection with the examples of FIG. 1 may be located external to system100, while in other instances, certain elements may be included withinor as a portion of one or more of the other described elements, as wellas other elements not described in the illustrated implementation.Further, certain elements illustrated in FIG. 1 may be combined withother components, as well as used for alternative or additional purposesin addition to those purposes described herein.

Additional embodiments associated with the implementation of a visualfog computing system 100 are described further in connection with theremaining FIGURES. Accordingly, it should be appreciated that visual fogsystem 100 of FIG. 1 may be implemented with any aspects of theembodiments described throughout this disclosure.

Example Internet-of-Things (IoT) Implementations

FIGS. 2-5 illustrate examples of Internet-of-Things (IoT) networks anddevices that can be used in accordance with embodiments disclosedherein. For example, the operations and functionality describedthroughout this disclosure may be embodied by an IoT device or machinein the example form of an electronic processing system, within which aset or sequence of instructions may be executed to cause the electronicprocessing system to perform any one of the methodologies discussedherein, according to an example embodiment. The machine may be an IoTdevice or an IoT gateway, including a machine embodied by aspects of apersonal computer (PC), a tablet PC, a personal digital assistant (PDA),a mobile telephone or smartphone, or any machine capable of executinginstructions (sequential or otherwise) that specify actions to be takenby that machine. Further, while only a single machine may be depictedand referenced in the example above, such machine shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein. Further, these and like examples toa processor-based system shall be taken to include any set of one ormore machines that are controlled by or operated by a processor (e.g., acomputer) to individually or jointly execute instructions to perform anyone or more of the methodologies discussed herein.

FIG. 2 illustrates an example domain topology for respectiveinternet-of-things (IoT) networks coupled through links to respectivegateways. The internet of things (IoT) is a concept in which a largenumber of computing devices are interconnected to each other and to theInternet to provide functionality and data acquisition at very lowlevels. Thus, as used herein, an IoT device may include a semiautonomousdevice performing a function, such as sensing or control, among others,in communication with other IoT devices and a wider network, such as theInternet.

Often, IoT devices are limited in memory, size, or functionality,allowing larger numbers to be deployed for a similar cost to smallernumbers of larger devices. However, an IoT device may be a smart phone,laptop, tablet, or PC, or other larger device. Further, an IoT devicemay be a virtual device, such as an application on a smart phone orother computing device. IoT devices may include IoT gateways, used tocouple IoT devices to other IoT devices and to cloud applications, fordata storage, process control, and the like.

Networks of IoT devices may include commercial and home automationdevices, such as water distribution systems, electric power distributionsystems, pipeline control systems, plant control systems, lightswitches, thermostats, locks, cameras, alarms, motion sensors, and thelike. The IoT devices may be accessible through remote computers,servers, and other systems, for example, to control systems or accessdata.

The future growth of the Internet and like networks may involve verylarge numbers of IoT devices. Accordingly, in the context of thetechniques discussed herein, a number of innovations for such futurenetworking will address the need for all these layers to growunhindered, to discover and make accessible connected resources, and tosupport the ability to hide and compartmentalize connected resources.Any number of network protocols and communications standards may beused, wherein each protocol and standard is designed to address specificobjectives. Further, the protocols are part of the fabric supportinghuman accessible services that operate regardless of location, time orspace. The innovations include service delivery and associatedinfrastructure, such as hardware and software; security enhancements;and the provision of services based on Quality of Service (QoS) termsspecified in service level and service delivery agreements. As will beunderstood, the use of IoT devices and networks, such as thoseintroduced in FIGS. 2-5, present a number of new challenges in aheterogeneous network of connectivity comprising a combination of wiredand wireless technologies.

FIG. 2 specifically provides a simplified drawing of a domain topologythat may be used for a number of internet-of-things (IoT) networkscomprising IoT devices 204, with the IoT networks 256, 258, 260, 262,coupled through backbone links 202 to respective gateways 254. Forexample, a number of IoT devices 204 may communicate with a gateway 254,and with each other through the gateway 254. To simplify the drawing,not every IoT device 204, or communications link (e.g., link 216, 222,228, or 232) is labeled. The backbone links 202 may include any numberof wired or wireless technologies, including optical networks, and maybe part of a local area network (LAN), a wide area network (WAN), or theInternet. Additionally, such communication links facilitate opticalsignal paths among both IoT devices 204 and gateways 254, including theuse of MUXing/deMUXing components that facilitate interconnection of thevarious devices.

The network topology may include any number of types of IoT networks,such as a mesh network provided with the network 256 using Bluetooth lowenergy (BLE) links 222. Other types of IoT networks that may be presentinclude a wireless local area network (WLAN) network 258 used tocommunicate with IoT devices 204 through IEEE 802.11 (Wi-Fi®) links 228,a cellular network 260 used to communicate with IoT devices 204 throughan LTE/LTE-A (4G) or 5G cellular network, and a low-power wide area(LPWA) network 262, for example, a LPWA network compatible with theLoRaWan specification promulgated by the LoRa alliance, or a IPv6 overLow Power Wide-Area Networks (LPWAN) network compatible with aspecification promulgated by the Internet Engineering Task Force (IETF).Further, the respective IoT networks may communicate with an outsidenetwork provider (e.g., a tier 2 or tier 3 provider) using any number ofcommunications links, such as an LTE cellular link, an LPWA link, or alink based on the IEEE 802.15.4 standard, such as Zigbee®. Therespective IoT networks may also operate with use of a variety ofnetwork and internet application protocols such as ConstrainedApplication Protocol (CoAP). The respective IoT networks may also beintegrated with coordinator devices that provide a chain of links thatforms cluster tree of linked devices and networks.

Each of these IoT networks may provide opportunities for new technicalfeatures, such as those as described herein. The improved technologiesand networks may enable the exponential growth of devices and networks,including the use of IoT networks into as fog devices or systems. As theuse of such improved technologies grows, the IoT networks may bedeveloped for self-management, functional evolution, and collaboration,without needing direct human intervention. The improved technologies mayeven enable IoT networks to function without centralized controlledsystems. Accordingly, the improved technologies described herein may beused to automate and enhance network management and operation functionsfar beyond current implementations.

In an example, communications between IoT devices 204, such as over thebackbone links 202, may be protected by a decentralized system forauthentication, authorization, and accounting (AAA). In a decentralizedAAA system, distributed payment, credit, audit, authorization, andauthentication systems may be implemented across interconnectedheterogeneous network infrastructure. This allows systems and networksto move towards autonomous operations. In these types of autonomousoperations, machines may even contract for human resources and negotiatepartnerships with other machine networks. This may allow the achievementof mutual objectives and balanced service delivery against outlined,planned service level agreements as well as achieve solutions thatprovide metering, measurements, traceability and trackability. Thecreation of new supply chain structures and methods may enable amultitude of services to be created, mined for value, and collapsedwithout any human involvement.

Such IoT networks may be further enhanced by the integration of sensingtechnologies, such as sound, light, electronic traffic, facial andpattern recognition, smell, vibration, into the autonomous organizationsamong the IoT devices. The integration of sensory systems may allowsystematic and autonomous communication and coordination of servicedelivery against contractual service objectives, orchestration andquality of service (QoS) based swarming and fusion of resources. Some ofthe individual examples of network-based resource processing include thefollowing.

The mesh network 256, for instance, may be enhanced by systems thatperform inline data-to-information transforms. For example, self-formingchains of processing resources comprising a multi-link network maydistribute the transformation of raw data to information in an efficientmanner, and the ability to differentiate between assets and resourcesand the associated management of each. Furthermore, the propercomponents of infrastructure and resource based trust and serviceindices may be inserted to improve the data integrity, quality,assurance and deliver a metric of data confidence.

The WLAN network 258, for instance, may use systems that performstandards conversion to provide multi-standard connectivity, enablingIoT devices 204 using different protocols to communicate. Furthersystems may provide seamless interconnectivity across a multi-standardinfrastructure comprising visible Internet resources and hidden Internetresources.

Communications in the cellular network 260, for instance, may beenhanced by systems that offload data, extend communications to moreremote devices, or both. The LPWA network 262 may include systems thatperform non-Internet protocol (IP) to IP interconnections, addressing,and routing. Further, each of the IoT devices 204 may include theappropriate transceiver for wide area communications with that device.Further, each IoT device 204 may include other transceivers forcommunications using additional protocols and frequencies.

Finally, clusters of IoT devices may be equipped to communicate withother IoT devices as well as with a cloud network. This may allow theIoT devices to form an ad-hoc network between the devices, allowing themto function as a single device, which may be termed a fog device. Thisconfiguration is discussed further with respect to FIG. 3 below.

FIG. 3 illustrates a cloud computing network in communication with amesh network of IoT devices (devices 302) operating as a fog device atthe edge of the cloud computing network. The mesh network of IoT devicesmay be termed a fog 320, operating at the edge of the cloud 300. Tosimplify the diagram, not every IoT device 302 is labeled.

The fog 320 may be considered to be a massively interconnected networkwherein a number of IoT devices 302 are in communications with eachother, for example, by radio links 322. As an example, thisinterconnected network may be facilitated using an interconnectspecification released by the Open Connectivity Foundation™ (OCF). Thisstandard allows devices to discover each other and establishcommunications for interconnects. Other interconnection protocols mayalso be used, including, for example, the optimized link state routing(OLSR) Protocol, the better approach to mobile ad-hoc networking(B.A.T.M.A.N.) routing protocol, or the OMA Lightweight M2M (LWM2M)protocol, among others.

Three types of IoT devices 302 are shown in this example, gateways 304,data aggregators 326, and sensors 328, although any combinations of IoTdevices 302 and functionality may be used. The gateways 304 may be edgedevices that provide communications between the cloud 300 and the fog320, and may also provide the backend process function for data obtainedfrom sensors 328, such as motion data, flow data, temperature data, andthe like. The data aggregators 326 may collect data from any number ofthe sensors 328, and perform the back-end processing function for theanalysis. The results, raw data, or both may be passed along to thecloud 300 through the gateways 304. The sensors 328 may be full IoTdevices 302, for example, capable of both collecting data and processingthe data. In some cases, the sensors 328 may be more limited infunctionality, for example, collecting the data and allowing the dataaggregators 326 or gateways 304 to process the data.

Communications from any IoT device 302 may be passed along a convenientpath (e.g., a most convenient path) between any of the IoT devices 302to reach the gateways 304. In these networks, the number ofinterconnections provide substantial redundancy, allowing communicationsto be maintained, even with the loss of a number of IoT devices 302.Further, the use of a mesh network may allow IoT devices 302 that arevery low power or located at a distance from infrastructure to be used,as the range to connect to another IoT device 302 may be much less thanthe range to connect to the gateways 304.

The fog 320 provided from these IoT devices 302 may be presented todevices in the cloud 300, such as a server 306, as a single devicelocated at the edge of the cloud 300, e.g., a fog device. In thisexample, the alerts coming from the fog device may be sent without beingidentified as coming from a specific IoT device 302 within the fog 320.In this fashion, the fog 320 may be considered a distributed platformthat provides computing and storage resources to perform processing ordata-intensive tasks such as data analytics, data aggregation, andmachine-learning, among others.

In some examples, the IoT devices 302 may be configured using animperative programming style, e.g., with each IoT device 302 having aspecific function and communication partners. However, the IoT devices302 forming the fog device may be configured in a declarativeprogramming style, allowing the IoT devices 302 to reconfigure theiroperations and communications, such as to determine needed resources inresponse to conditions, queries, and device failures. As an example, aquery from a user located at a server 306 about the operations of asubset of equipment monitored by the IoT devices 302 may result in thefog 320 device selecting the IoT devices 302, such as particular sensors328, needed to answer the query. The data from these sensors 328 maythen be aggregated and analyzed by any combination of the sensors 328,data aggregators 326, or gateways 304, before being sent on by the fog320 device to the server 306 to answer the query. In this example, IoTdevices 302 in the fog 320 may select the sensors 328 used based on thequery, such as adding data from flow sensors or temperature sensors.Further, if some of the IoT devices 302 are not operational, other IoTdevices 302 in the fog 320 device may provide analogous data, ifavailable.

FIG. 4 illustrates a drawing of a cloud computing network, or cloud 400,in communication with a number of Internet of Things (IoT) devices. Thecloud 400 may represent the Internet, or may be a local area network(LAN), or a wide area network (WAN), such as a proprietary network for acompany. The IoT devices may include any number of different types ofdevices, grouped in various combinations. For example, a traffic controlgroup 406 may include IoT devices along streets in a city. These IoTdevices may include stoplights, traffic flow monitors, cameras, weathersensors, and the like. The traffic control group 406, or othersubgroups, may be in communication with the cloud 400 through wired orwireless links 408, such as LPWA links, optical links, and the like.Further, a wired or wireless sub-network 412 may allow the IoT devicesto communicate with each other, such as through a local area network, awireless local area network, and the like. The IoT devices may useanother device, such as a gateway 510 or 528 to communicate with remotelocations such as the cloud 500; the IoT devices may also use one ormore servers 530 to facilitate communication with the cloud 500 or withthe gateway 510. For example, the one or more servers 530 may operate asan intermediate network node to support a local edge cloud or fogimplementation among a local area network. Further, the gateway 528 thatis depicted may operate in a cloud-to-gateway-to-many edge devicesconfiguration, such as with the various IoT devices 514, 520, 524 beingconstrained or dynamic to an assignment and use of resources in thecloud 500.

Other example groups of IoT devices may include remote weather stations414, local information terminals 416, alarm systems 418, automatedteller machines 420, alarm panels 422, or moving vehicles, such asemergency vehicles 424 or other vehicles 426, among many others. Each ofthese IoT devices may be in communication with other IoT devices, withservers 404, with another IoT fog device or system (not shown, butdepicted in FIG. 3), or a combination therein. The groups of IoT devicesmay be deployed in various residential, commercial, and industrialsettings (including in both private or public environments).

As can be seen from FIG. 4, a large number of IoT devices may becommunicating through the cloud 400. This may allow different IoTdevices to request or provide information to other devices autonomously.For example, a group of IoT devices (e.g., the traffic control group406) may request a current weather forecast from a group of remoteweather stations 414, which may provide the forecast without humanintervention. Further, an emergency vehicle 424 may be alerted by anautomated teller machine 420 that a burglary is in progress. As theemergency vehicle 424 proceeds towards the automated teller machine 420,it may access the traffic control group 406 to request clearance to thelocation, for example, by lights turning red to block cross traffic atan intersection in sufficient time for the emergency vehicle 424 to haveunimpeded access to the intersection.

Clusters of IoT devices, such as the remote weather stations 414 or thetraffic control group 406, may be equipped to communicate with other IoTdevices as well as with the cloud 400. This may allow the IoT devices toform an ad-hoc network between the devices, allowing them to function asa single device, which may be termed a fog device or system (e.g., asdescribed above with reference to FIG. 3).

FIG. 5 is a block diagram of an example of components that may bepresent in an IoT device 550 for implementing the techniques describedherein. The IoT device 550 may include any combinations of thecomponents shown in the example or referenced in the disclosure above.The components may be implemented as ICs, portions thereof, discreteelectronic devices, or other modules, logic, hardware, software,firmware, or a combination thereof adapted in the IoT device 550, or ascomponents otherwise incorporated within a chassis of a larger system.Additionally, the block diagram of FIG. 5 is intended to depict ahigh-level view of components of the IoT device 550. However, some ofthe components shown may be omitted, additional components may bepresent, and different arrangement of the components shown may occur inother implementations.

The IoT device 550 may include a processor 552, which may be amicroprocessor, a multi-core processor, a multithreaded processor, anultra-low voltage processor, an embedded processor, or other knownprocessing element. The processor 552 may be a part of a system on achip (SoC) in which the processor 552 and other components are formedinto a single integrated circuit, or a single package, such as theEdison™ or Galileo™ SoC boards from Intel. As an example, the processor552 may include an Intel® Architecture Core™ based processor, such as aQuark™, an Atom™, an i3, an i5, an i7, or an MCU-class processor, oranother such processor available from Intel® Corporation, Santa Clara,Calif. However, any number other processors may be used, such asavailable from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, Calif.,a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, Calif.,an ARM-based design licensed from ARM Holdings, Ltd. or customerthereof, or their licensees or adopters. The processors may includeunits such as an A5-A10 processor from Apple® Inc., a Snapdragon™processor from Qualcomm® Technologies, Inc., or an OMAP™ processor fromTexas Instruments, Inc.

The processor 552 may communicate with a system memory 554 over aninterconnect 556 (e.g., a bus). Any number of memory devices may be usedto provide for a given amount of system memory. As examples, the memorymay be random access memory (RAM) in accordance with a Joint ElectronDevices Engineering Council (JEDEC) design such as the DDR or mobile DDRstandards (e.g., LPDDR, LPDDR2, LPDDR3, or LPDDR4). In variousimplementations, the individual memory devices may be of any number ofdifferent package types such as single die package (SDP), dual diepackage (DDP) or quad die package (Q17P). These devices, in someexamples, may be directly soldered onto a motherboard to provide a lowerprofile solution, while in other examples the devices are configured asone or more memory modules that in turn couple to the motherboard by agiven connector. Any number of other memory implementations may be used,such as other types of memory modules, e.g., dual inline memory modules(DIMMs) of different varieties including but not limited to microDIMMsor MiniDIMMs.

To provide for persistent storage of information such as data,applications, operating systems and so forth, a storage 558 may alsocouple to the processor 552 via the interconnect 556. In an example, thestorage 558 may be implemented via a solid state disk drive (SSDD).Other devices that may be used for the storage 558 include flash memorycards, such as SD cards, microSD cards, xD picture cards, and the like,and USB flash drives. In low power implementations, the storage 558 maybe on-die memory or registers associated with the processor 552.However, in some examples, the storage 558 may be implemented using amicro hard disk drive (HDD). Further, any number of new technologies maybe used for the storage 558 in addition to, or instead of, thetechnologies described, such resistance change memories, phase changememories, holographic memories, or chemical memories, among others.

The components may communicate over the interconnect 556. Theinterconnect 556 may include any number of technologies, includingindustry standard architecture (ISA), extended ISA (EISA), peripheralcomponent interconnect (PCI), peripheral component interconnect extended(PCIx), PCI express (PCIe), or any number of other technologies. Theinterconnect 556 may be a proprietary bus, for example, used in a SoCbased system. Other bus systems may be included, such as an I2Cinterface, an SPI interface, point to point interfaces, and a power bus,among others.

The interconnect 556 may couple the processor 552 to a mesh transceiver562, for communications with other mesh devices 564. The meshtransceiver 562 may use any number of frequencies and protocols, such as2.4 Gigahertz (GHz) transmissions under the IEEE 802.15.4 standard,using the Bluetooth® low energy (BLE) standard, as defined by theBluetooth® Special Interest Group, or the ZigBee® standard, amongothers. Any number of radios, configured for a particular wirelesscommunication protocol, may be used for the connections to the meshdevices 564. For example, a WLAN unit may be used to implement Wi-Fi™communications in accordance with the Institute of Electrical andElectronics Engineers (IEEE) 802.11 standard. In addition, wireless widearea communications, e.g., according to a cellular or other wirelesswide area protocol, may occur via a WWAN unit.

The mesh transceiver 562 may communicate using multiple standards orradios for communications at different range. For example, the IoTdevice 550 may communicate with close devices, e.g., within about 10meters, using a local transceiver based on BLE, or another low powerradio, to save power. More distant mesh devices 564, e.g., within about50 meters, may be reached over ZigBee or other intermediate powerradios. Both communications techniques may take place over a singleradio at different power levels, or may take place over separatetransceivers, for example, a local transceiver using BLE and a separatemesh transceiver using ZigBee.

A wireless network transceiver 566 may be included to communicate withdevices or services in the cloud 500 via local or wide area networkprotocols. The wireless network transceiver 566 may be a LPWAtransceiver that follows the IEEE 802.15.4, or IEEE 802.15.4g standards,among others. The IoT device 550 may communicate over a wide area usingLoRaWAN™ (Long Range Wide Area Network) developed by Semtech and theLoRa Alliance. The techniques described herein are not limited to thesetechnologies, but may be used with any number of other cloudtransceivers that implement long range, low bandwidth communications,such as Sigfox, and other technologies. Further, other communicationstechniques, such as time-slotted channel hopping, described in the IEEE802.15.4e specification may be used.

Any number of other radio communications and protocols may be used inaddition to the systems mentioned for the mesh transceiver 562 andwireless network transceiver 566, as described herein. For example, theradio transceivers 562 and 566 may include an LTE or other cellulartransceiver that uses spread spectrum (SPA/SAS) communications forimplementing high speed communications. Further, any number of otherprotocols may be used, such as Wi-Fi® networks for medium speedcommunications and provision of network communications.

The radio transceivers 562 and 566 may include radios that arecompatible with any number of 3GPP (Third Generation PartnershipProject) specifications, notably Long Term Evolution (LTE), Long TermEvolution-Advanced (LTE-A), and Long Term Evolution-Advanced Pro (LTE-APro). It can be noted that radios compatible with any number of otherfixed, mobile, or satellite communication technologies and standards maybe selected. These may include, for example, any Cellular Wide Arearadio communication technology, which may include e.g. a 5th Generation(5G) communication systems, a Global System for Mobile Communications(GSM) radio communication technology, a General Packet Radio Service(GPRS) radio communication technology, or an Enhanced Data Rates for GSMEvolution (EDGE) radio communication technology, a UMTS (UniversalMobile Telecommunications System) communication technology, In additionto the standards listed above, any number of satellite uplinktechnologies may be used for the wireless network transceiver 566,including, for example, radios compliant with standards issued by theITU (International Telecommunication Union), or the ETSI (EuropeanTelecommunications Standards Institute), among others. The examplesprovided herein are thus understood as being applicable to various othercommunication technologies, both existing and not yet formulated.

A network interface controller (NIC) 568 may be included to provide awired communication to the cloud 500 or to other devices, such as themesh devices 564. The wired communication may provide an Ethernetconnection, or may be based on other types of networks, such asController Area Network (CAN), Local Interconnect Network (LIN),DeviceNet, ControlNet, Data Highway+, PROFIBUS, or PROFINET, among manyothers. An additional NIC 568 may be included to allow connect to asecond network, for example, a NIC 568 providing communications to thecloud over Ethernet, and a second NIC 568 providing communications toother devices over another type of network.

The interconnect 556 may couple the processor 552 to an externalinterface 570 that is used to connect external devices or subsystems.The external devices may include sensors 572, such as accelerometers,level sensors, flow sensors, optical light sensors, camera sensors,temperature sensors, a global positioning system (GPS) sensors, pressuresensors, barometric pressure sensors, and the like. The externalinterface 570 further may be used to connect the IoT device 550 toactuators 574, such as power switches, valve actuators, an audible soundgenerator, a visual warning device, and the like.

In some optional examples, various input/output (I/O) devices may bepresent within, or connected to, the IoT device 550. For example, adisplay or other output device 584 may be included to show information,such as sensor readings or actuator position. An input device 586, suchas a touch screen or keypad may be included to accept input. An outputdevice 584 may include any number of forms of audio or visual display,including simple visual outputs such as binary status indicators (e.g.,LEDs) and multi-character visual outputs, or more complex outputs suchas display screens (e.g., LCD screens), with the output of characters,graphics, multimedia objects, and the like being generated or producedfrom the operation of the IoT device 550.

A battery 576 may power the IoT device 550, although in examples inwhich the IoT device 550 is mounted in a fixed location, it may have apower supply coupled to an electrical grid. The battery 576 may be alithium ion battery, or a metal-air battery, such as a zinc-air battery,an aluminum-air battery, a lithium-air battery, and the like.

A battery monitor/charger 578 may be included in the IoT device 550 totrack the state of charge (SoCh) of the battery 576. The batterymonitor/charger 578 may be used to monitor other parameters of thebattery 576 to provide failure predictions, such as the state of health(SoH) and the state of function (SoF) of the battery 576. The batterymonitor/charger 578 may include a battery monitoring integrated circuit,such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488Afrom ON Semiconductor of Phoenix Ariz., or an IC from the UCD90xxxfamily from Texas Instruments of Dallas, Tex. The batterymonitor/charger 578 may communicate the information on the battery 576to the processor 552 over the interconnect 556. The batterymonitor/charger 578 may also include an analog-to-digital (ADC)convertor that allows the processor 552 to directly monitor the voltageof the battery 576 or the current flow from the battery 576. The batteryparameters may be used to determine actions that the IoT device 550 mayperform, such as transmission frequency, mesh network operation, sensingfrequency, and the like.

A power block 580, or other power supply coupled to a grid, may becoupled with the battery monitor/charger 578 to charge the battery 576.In some examples, the power block 580 may be replaced with a wirelesspower receiver to obtain the power wirelessly, for example, through aloop antenna in the IoT device 550. A wireless battery charging circuit,such as an LTC4020 chip from Linear Technologies of Milpitas, Calif.,among others, may be included in the battery monitor/charger 578. Thespecific charging circuits chosen depend on the size of the battery 576,and thus, the current required. The charging may be performed using theAirfuel standard promulgated by the Airfuel Alliance, the Qi wirelesscharging standard promulgated by the Wireless Power Consortium, or theRezence charging standard, promulgated by the Alliance for WirelessPower, among others.

The storage 558 may include instructions 582 in the form of software,firmware, or hardware commands to implement the techniques describedherein. Although such instructions 582 are shown as code blocks includedin the memory 554 and the storage 558, it may be understood that any ofthe code blocks may be replaced with hardwired circuits, for example,built into an application specific integrated circuit (ASIC).

In an example, the instructions 582 provided via the memory 554, thestorage 558, or the processor 552 may be embodied as a non-transitory,machine readable medium 560 including code to direct the processor 552to perform electronic operations in the IoT device 550. The processor552 may access the non-transitory, machine readable medium 560 over theinterconnect 556. For instance, the non-transitory, machine readablemedium 560 may include storage units such as optical disks, flashdrives, or any number of other hardware devices. The non-transitory,machine readable medium 560 may include instructions to direct theprocessor 552 to perform a specific sequence or flow of actions, forexample, as described with respect to the flowchart(s) and diagram(s) ofoperations and functionality described throughout this disclosure.

Example Computing Architectures

FIGS. 6 and 7 illustrate example computer processor architectures thatcan be used in accordance with embodiments disclosed herein. Forexample, in various embodiments, the computer architectures of FIGS. 6and 7 may be used to implement the visual fog functionality describedthroughout this disclosure. Other embodiments may use other processorand system designs and configurations known in the art, for example, forlaptops, desktops, handheld PCs, personal digital assistants,engineering workstations, servers, network devices, network hubs,switches, embedded processors, digital signal processors (DSPs),graphics devices, video game devices, set-top boxes, micro controllers,cell phones, portable media players, hand held devices, and variousother electronic devices, are also suitable. In general, a huge varietyof systems or electronic devices capable of incorporating a processorand/or other execution logic as disclosed herein are generally suitable.

FIG. 6 illustrates a block diagram for an example embodiment of aprocessor 600. Processor 600 is an example of a type of hardware devicethat can be used in connection with the embodiments described throughoutthis disclosure. Processor 600 may be any type of processor, such as amicroprocessor, an embedded processor, a digital signal processor (DSP),a network processor, a multi-core processor, a single core processor, orother device to execute code. Although only one processor 600 isillustrated in FIG. 6, a processing element may alternatively includemore than one of processor 600 illustrated in FIG. 6. Processor 600 maybe a single-threaded core or, for at least one embodiment, the processor600 may be multi-threaded in that it may include more than one hardwarethread context (or “logical processor”) per core.

FIG. 6 also illustrates a memory 602 coupled to processor 600 inaccordance with an embodiment. Memory 602 may be any of a wide varietyof memories (including various layers of memory hierarchy) as are knownor otherwise available to those of skill in the art. Such memoryelements can include, but are not limited to, random access memory(RAM), read only memory (ROM), logic blocks of a field programmable gatearray (FPGA), erasable programmable read only memory (EPROM), andelectrically erasable programmable ROM (EEPROM).

Processor 600 can execute any type of instructions associated withalgorithms, processes, or operations detailed herein. Generally,processor 600 can transform an element or an article (e.g., data) fromone state or thing to another state or thing.

Code 604, which may be one or more instructions to be executed byprocessor 600, may be stored in memory 602, or may be stored insoftware, hardware, firmware, or any suitable combination thereof, or inany other internal or external component, device, element, or objectwhere appropriate and based on particular needs. In one example,processor 600 can follow a program sequence of instructions indicated bycode 604. Each instruction enters a front-end logic 606 and is processedby one or more decoders 608. The decoder may generate, as its output, amicro operation such as a fixed width micro operation in a predefinedformat, or may generate other instructions, microinstructions, orcontrol signals that reflect the original code instruction. Front-endlogic 606 may also include register renaming logic and scheduling logic,which generally allocate resources and queue the operation correspondingto the instruction for execution.

Processor 600 can also include execution logic 614 having a set ofexecution units 616 a, 616 b, 616 n, etc. Some embodiments may include anumber of execution units dedicated to specific functions or sets offunctions. Other embodiments may include only one execution unit or oneexecution unit that can perform a particular function. Execution logic614 performs the operations specified by code instructions.

After completion of execution of the operations specified by the codeinstructions, back-end logic 618 can retire the instructions of code604. In one embodiment, processor 600 allows out of order execution butrequires in order retirement of instructions. Retirement logic 620 maytake a variety of known forms (e.g., re-order buffers or the like). Inthis manner, processor 600 is transformed during execution of code 604,at least in terms of the output generated by the decoder, hardwareregisters and tables utilized by register renaming logic 610, and anyregisters (not shown) modified by execution logic 614.

Although not shown in FIG. 6, a processing element may include otherelements on a chip with processor 600. For example, a processing elementmay include memory control logic along with processor 600. Theprocessing element may include I/O control logic and/or may include I/Ocontrol logic integrated with memory control logic. The processingelement may also include one or more caches. In some embodiments,non-volatile memory (such as flash memory or fuses) may also be includedon the chip with processor 600.

FIG. 7 illustrates a block diagram for an example embodiment of amultiprocessor 700. As shown in FIG. 7, multiprocessor system 700 is apoint-to-point interconnect system, and includes a first processor 770and a second processor 780 coupled via a point-to-point interconnect750. In some embodiments, each of processors 770 and 780 may be someversion of processor 600 of FIG. 6.

Processors 770 and 780 are shown including integrated memory controller(IMC) units 772 and 782, respectively. Processor 770 also includes aspart of its bus controller units point-to-point (P-P) interfaces 776 and778; similarly, second processor 780 includes P-P interfaces 786 and788. Processors 770, 780 may exchange information via a point-to-point(P-P) interface 750 using P-P interface circuits 778, 788. As shown inFIG. 7, IMCs 772 and 782 couple the processors to respective memories,namely a memory 732 and a memory 734, which may be portions of mainmemory locally attached to the respective processors.

Processors 770, 780 may each exchange information with a chipset 790 viaindividual P-P interfaces 752, 754 using point to point interfacecircuits 776, 794, 786, 798. Chipset 790 may optionally exchangeinformation with the coprocessor 738 via a high-performance interface739. In one embodiment, the coprocessor 738 is a special-purposeprocessor, such as, for example, a high-throughput MIC processor, anetwork or communication processor, compression engine, graphicsprocessor, GPGPU, embedded processor, matrix processor, or the like.

A shared cache (not shown) may be included in either processor oroutside of both processors, yet connected with the processors via P-Pinterconnect, such that either or both processors' local cacheinformation may be stored in the shared cache if a processor is placedinto a low power mode.

Chipset 790 may be coupled to a first bus 716 via an interface 796. Inone embodiment, first bus 716 may be a Peripheral Component Interconnect(PCI) bus, or a bus such as a PCI Express bus or another thirdgeneration I/O interconnect bus, although the scope of this disclosureis not so limited.

As shown in FIG. 7, various I/O devices 714 may be coupled to first bus716, along with a bus bridge 718 which couples first bus 716 to a secondbus 720. In one embodiment, one or more additional processor(s) 715,such as coprocessors, high-throughput MIC processors, GPGPU's,accelerators (such as, e.g., graphics accelerators or digital signalprocessing (DSP) units), matrix processors, field programmable gatearrays, or any other processor, are coupled to first bus 716. In oneembodiment, second bus 720 may be a low pin count (LPC) bus. Variousdevices may be coupled to a second bus 720 including, for example, akeyboard and/or mouse 722, communication devices 727 and a storage unit728 such as a disk drive or other mass storage device which may includeinstructions/code and data 730, in one embodiment. Further, an audio I/O724 may be coupled to the second bus 720. Note that other architecturesare possible. For example, instead of the point-to-point architecture ofFIG. 7, a system may implement a multi-drop bus or other sucharchitecture.

All or part of any component of FIG. 7 may be implemented as a separateor stand-alone component or chip, or may be integrated with othercomponents or chips, such as a system-on-a-chip (SoC) that integratesvarious computer components into a single chip.

Embodiments of the mechanisms disclosed herein may be implemented inhardware, software, firmware, or a combination of such implementationapproaches. Certain embodiments may be implemented as computer programsor program code executing on programmable systems comprising at leastone processor, a storage system (including volatile and non-volatilememory and/or storage elements), at least one input device, and at leastone output device.

Program code, such as code 730 illustrated in FIG. 7, may be applied toinput instructions to perform the functions described herein andgenerate output information. The output information may be applied toone or more output devices, in known fashion. For purposes of thisapplication, a processing system includes any system that has aprocessor, such as, for example; a digital signal processor (DSP), amicrocontroller, an application specific integrated circuit (ASIC), or amicroprocessor.

The program code may be implemented in a high level procedural or objectoriented programming language to communicate with a processing system.The program code may also be implemented in assembly or machinelanguage, if desired. In fact, the mechanisms described herein are notlimited in scope to any particular programming language. In any case,the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented byrepresentative instructions stored on a machine-readable medium whichrepresents various logic within the processor, which when read by amachine causes the machine to fabricate logic to perform the techniquesdescribed herein. Such representations, known as “IP cores” may bestored on a tangible, machine readable medium and supplied to variouscustomers or manufacturing facilities to load into the fabricationmachines that actually make the logic or processor.

Such machine-readable storage media may include, without limitation,non-transitory, tangible arrangements of articles manufactured or formedby a machine or device, including storage media such as hard disks, anyother type of disk including floppy disks, optical disks, compact diskread-only memories (CD-ROMs), compact disk rewritable's (CD-RWs), andmagneto-optical disks, semiconductor devices such as read-only memories(ROMs), random access memories (RAMS) such as dynamic random accessmemories (DRAMs), static random access memories (SRAMs), erasableprogrammable read-only memories (EPROMs), flash memories, electricallyerasable programmable read-only memories (EEPROMs), phase change memory(PCM), magnetic or optical cards, or any other type of media suitablefor storing electronic instructions.

Accordingly, embodiments of this disclosure also include non-transitory,tangible machine-readable media containing instructions or containingdesign data, such as Hardware Description Language (HDL), which definesstructures, circuits, apparatuses, processors and/or system featuresdescribed herein. Such embodiments may also be referred to as programproducts.

Visual Fog Architecture

FIG. 8 illustrates an example embodiment of an architecture 800 forvisual fog nodes. In some embodiments, for example, fog nodearchitecture 800 may be used to implement the functionality of fog nodes810 in a visual fog network or system (e.g., visual fog system 100 ofFIG. 1). A fog node 810, for example, can include any node or componentthat ranges from the edge of a network to the cloud, inclusively.

In the illustrated embodiment, fog node 810 includes various applicationprogramming interfaces (APIs) that provide fundamental capabilities forfog node 810, such as auxiliary API 820, primitive vision API 830, andstorage API 840. In some embodiments, for example, these APIs may beused or implemented by lower-level algorithm developers.

Auxiliary API 820 provides various fundamental functionality for fognode 810, such as security 822 a, communication 822 b, compression 822 c(e.g., codecs), and so forth.

Primitive vision API 830 provides fundamental vision processingcapabilities for fog node 810. For example, primitive vision API 830provides access to a plurality of vision kernels 832 that can be used toperform primitive vision operations (e.g., person or object detection,facial recognition). Primitive vision API 830 may also provide access tovarious machine learning and/or neural network frameworks (e.g., Caffe,OpenCV, TensorFlow).

Storage API 840 provides storage capabilities for fog node 810. In someembodiments, for example, storage API 840 may include a variety ofdatabases 842 for storing different types of visual data, such as graphdatabases, relational databases, array-based databases (e.g., TileDB),and so forth. In some embodiments, for example, the particular databaseused to store certain visual data may depend on the type of data, suchas raw visual data or pixels, compressed visual data, visual metadata,and so forth.

Moreover, fog node 810 further includes a vision application API 850that provides higher-level vision functionality, which may be used orimplemented by developers of vision applications. For example, visionapplication API 850 may include a privacy policy 852 that defines therequisite privacy treatment for all data and devices associated with avisual fog network. Vision application API 850 may also include a visionkernel management service 854 that provides access to a variety ofprimitive vision operations or vision kernels. In some embodiments, forexample, vision kernel management service 854 may retrieve visionkernels from a vision kernel repository. For example, if a particularvision application employs person detection functionality, vision kernelmanagement service 854 may retrieve the appropriate vision kernel forperforming person detection using the available hardware of theparticular fog node 810.

Fog node 810 further includes a vision analytics API 860 and query API870, which may be used by end-users or operators to perform visualanalytics and visual queries. For example, vision analytics API 860 mayperform inline (e.g. real-time) and/or offline processing of visualdata, application launching, scheduling, resource monitoring, and soforth. Vision analytics API 860 may also include a vision applicationmanagement service 862 that provides access to a variety of visionapplications (e.g., people searching/tracking, objectdetection/tracking, and so forth). In some embodiments, for example,vision application management service 862 may retrieve visionapplications from a vision application repository. In this manner, if anend-user wants to perform a people search, vision application managementservice 862 may retrieve an appropriate vision application for peoplesearching. In some embodiments, for example, a people search visionapplication may use vision kernels that perform person detectionfollowed by facial recognition. The end-user, however, can utilize thepeople search vision application without any knowledge of the underlyingvision kernels or vision operations used to implement the application.

Moreover, query API 870 provides an interface that enables end-users tosubmit visual search requests or queries. In some embodiments, forexample, query API 870 may support flexible visual queries in a varietyof syntaxes, such as natural language, functional syntax (e.g., usinglogical operators), relational syntax, and so forth. In someembodiments, query API 870 may further include a query primitiverepository 874 that contains the primitive operations that are supportedfor visual queries. Moreover, query API 870 may include a query compiler872 for compiling the visual queries into visual processing dataflowsthat can be executed by visual fog nodes.

FIG. 9-12A-12B illustrate example embodiments of visual fogarchitectures.

For example, FIG. 9 illustrates an example visual fog architecture 900that includes cameras 902, sensors 904, local analytics framework 906,inline analytics framework 908, offline analytics framework 910, storage912, and presentation/interpretation framework 914. In the illustratedembodiment, for example, cameras 902 and/or sensors 904 may generatevisual data, such as images and/or video. The visual data may then beprovided to local analytics framework 906, which may be used to performpreliminary processing and analytics at the network edge (e.g., near thecameras 902 or sensors 904 that captured the visual data). The partiallyprocessed visual data may then be provided to inline analytics framework908 for further processing in real-time. In various embodiments, forexample, inline analytics may be performed by and/or distributed acrossany combination of fog devices or resources (e.g., mobile devices, IoTdevices, gateways, and/or the cloud). The resulting visual data and/ormetadata from inline analytics framework 908 may then be stored in datastorage 912. Moreover, a visual search query may be subsequentlyreceived by presentation/interpretation framework 914 (e.g., from anend-user). Accordingly, presentation/interpretation framework 914 mayinteract with data storage 912 and/or inline analytics framework 908 todetermine whether a response to the query can be formulated based on thevisual data and/or metadata that has already been processed orgenerated. If further processing needs to be performed to respond to thequery, however, presentation/interpretation framework 914 may interactwith offline analytics framework 910 to perform further offlineprocessing of the visual data. In various embodiments, for example,offline analytics may be performed by and/or distributed across anycombination of fog devices or resources (e.g., mobile devices, IoTdevices, gateways, and/or the cloud). Accordingly, based on theinformation obtained either from data storage 912, inline analyticsframework 908, and/or offline analytics framework 910,presentation/interpretation framework 914 may then respond to the visualquery.

FIG. 10 illustrates an example visual processing pipeline 1000associated with a visual fog architecture. In the illustrated example,visual data 1002 may first be captured by cameras and/or visual sensors,and the visual data 1002 may then be processed to perform certain visualfunctions 1004 (e.g., face detection) and/or other analytics, resultingin a set of visual metadata 1012 that may be stored in data storage1010. Moreover, an end-user may subsequently submit an ad hoc searchquery 1006 associated with the visual data 1002, and a querycompiler/interpreter 1008 may then compile the query into a visualprocessing dataflow that can be executed (e.g., using available fognodes or resources) in order to respond to the query. In some cases, forexample, it may be possible to formulate a query result 1016 based onthe processing that has already been completed. For example, in somecases, the query result 1016 may be formulated by applying appropriatelogic operations 1014 on the existing visual metadata 1012 that hasalready been generated. In other cases, however, further visualprocessing and/or functions 1004 may need to be performed on the visualdata 1002 in order to formulate the query result 1016. In either case,the compiler/interpreter 1008 may generate a requisite vision processingdataflow for responding to the query, and the resulting visionprocessing dataflow may then be executed in order to formulate the queryresult 1016.

FIG. 11 illustrates another example visual fog architecture 1100. In theillustrated embodiment, visual data captured by cameras 1140 b isprovided to a distributed runtime environment 1120, which performsinitial pre-processing on the visual data in real-time (e.g., when thevisual data is first captured rather than in response to a query). Theresulting visual data or metadata generated by the distributed runtimeenvironment 1120 is then stored in data storage 1130.

Separately, visual search queries containing user-defined visionfunctions (UVFs) 1104 a-c are received from end-users 1102 of visual fog1100. A UVF 1104 received from an end-user 1102 is first processed by acompiler 1110 in order to generate a vision dataflow graph for executingthe UVF. Accordingly, the vision dataflow graph is then executed by thedistributed runtime environment 1120 in order to generate a result forthe UVF 1104. In some embodiments, for example, the distributed runtimeenvironment 1120 may determine the result using existing visual metadatathat has already been generated (e.g., from the initial or real-timeprocessing of the original visual data), and/or by performing furtheranalysis on the visual data (e.g., by executing a particular visionapplication 1150). The result obtained from execution of the UVF 1104may then be provided back to the requesting end-user 1102.

Further, in various embodiments, the distributed runtime environment1120 may perform the described visual data processing (e.g., initialpre-processing and/or UVF processing) by scheduling or distributingvision workloads across the available fog devices or resources 1140(e.g., cloud servers 1140 a, cameras 1140 b, mobile devices, IoTdevices, gateways, and/or other fog/edge devices).

FIGS. 12A-12B illustrate another example visual fog architecture 1200.In the illustrated embodiment, visual fog architecture 1200 includes anetwork of fog devices 1216, including cameras or visual sensors 1216 a,gateways 1216 b, and cloud servers 1216 c. The cameras or visual sensors1216 a, for example, are used to capture visual data 1217. Moreover, acomputer vision expert 1202 can develop an imperative vision program1203 that leverages the captured visual data 1217. The vision program1203, for example, may be implemented using programming andcomposability frameworks 1208 and 1210 to define vision processingdataflows 1209 and generate vision processing workloads 1211.

In the illustrated embodiment, for example, the vision program 1203leverages a distributed runtime environment 1214 to process visual data1217 captured in visual fog 1200. The distributed runtime environment1214, for example, can perform visual data processing using thecollection of available fog devices 1216 in visual fog 1200.

In some embodiments, for example, the distributed runtime environment1214 may be used to perform initial pre-processing on captured visualdata 1217 in real-time (e.g., when the visual data is first capturedrather than in response to a query). The resulting visual data ormetadata 1217 generated by the distributed runtime environment 1214 maythen be stored in a database or data storage 1218.

Moreover, a layperson or end-user 1204 may subsequently submit adeclarative query 1205 associated with visual data 1217 captured byvisual fog 1200. The declarative query 1205 is processed by a visualquestion answering (VQA) system 1206, which uses a compiler orinterpreter to generate a dataflow 1209 for responding to the query. Insome cases, for example, it may be possible to respond to query 1205using existing visual metadata 1217 that has already been generated(e.g., during the initial or real-time processing of the original visualdata 1217 and/or during the processing associated with prior queries1205). In other cases, however, further processing may need to beperformed on the visual data 1217 in order to respond to the query 1205.In either case, an appropriate dataflow 1209 for responding to the query1205 may be generated, and the resulting dataflow 1209 may be furtherpartitioned into one or more underlying vision processing workloads1211. Moreover, based on the resource availability 1215 of fog devices1216 in the distributed runtime environment 1214, a schedule 1213 fordistributing the workloads 1211 across the available fog devices 1216may be generated. Accordingly, the respective workloads 1211 may then bedistributed across the fog devices 1216 based on the generated schedule1213, and each fog device 1216 may execute its respective workload(s)1211. In this manner, the dataflow 1209 for responding to the query 1205is executed by the various fog devices 1216 using a distributedapproach. A response to the query 1205 may then be provided to theend-user 1204, and the resulting visual metadata 1217 may be stored indatabase 1218 for responding to subsequent queries.

Visual Question Answering (VQA)

FIG. 13-14 illustrate example embodiments associated with a visualquestion answering (VQA) framework. In some embodiments, for example, avisual fog architecture may implement a VQA framework to provide aflexible and efficient interface for end-users to submit ad hoc visualsearch queries. In visual processing systems, for example, the abilityto submit a query to search large data sets in an efficient manner(e.g., millions of images) and identify a subset of relevant images orrelated information is important. Existing visual processing solutionsare implemented using rigid or inflexible approaches, however, and areunable to search visual data efficiently. Accordingly, the visualquestion answering (VQA) framework of FIGS. 13 and 14 can be used toalleviate the deficiencies of existing solutions.

In some embodiments, for example, a VQA framework may support flexibleor ad hoc visual search queries using a variety of syntaxes, such asnatural language, functional syntax (e.g., using logical operators),relational syntax, and so forth. Accordingly, when a visual search queryis received from a user, the query may be compiled into a visualprocessing dataflow that can be distributed across and executed by thevarious fog nodes in a visual fog architecture. In this manner,end-users can perform complex searches on large sets of visual datawithout any knowledge of the underlying architecture or processingrequired to execute the searches.

Moreover, in some embodiments, users or developers may be capable ofdefining custom vision functions that can be used in visual searchqueries, referred to as user-defined vision functions (UVFs). As anexample, a UVF could be defined for visually equivalency, or performing“equal” operations on visual data. Many ad hoc visual queries, forexample, require information related to the same object or person to beidentified or grouped together. Identifying the same object or personacross different images or video streams, however, can be challenging.In some embodiments, for example, this task may require featureextraction to be performed across multiple cameras. The respectivefeatures extracted from each camera often differ, however, and not allcameras have the same field of view, and thus certain features may besuccessfully extracted from some cameras but not others. Accordingly, insome embodiments, a user may implement a UVF to define how visualequivalency or “equal” operations are to be performed on visual data. Insome embodiments, for example, a UVF for visual equivalency may defineobjects as “equal” if their feature vectors are “close enough” to eachother, meaning the feature vectors must be sufficiently similar but donot have to be an exact match. Further, if feature vectors fromdifferent cameras are missing certain features, only the partialfeatures will be compared and the “close enough” definition will bescaled accordingly.

FIG. 13 illustrates an example embodiment of a visual question answering(VQA) pipeline 1300. In the illustrated example, a visual query 1302 isfirst received from an end-user, and a dataflow compiler 1304 is thenused to compile the visual query 1302 into a visual processing pipelineor dataflow 1308. In some embodiments, for example, the dataflowcompiler 1304 may use a library of vision kernel modules 1306 (e.g.,face recognition, pose recognition, object recognition, and so forth) togenerate the resulting visual processing dataflow 1308.

In some cases, for example, the visual processing dataflow 1308 mayleverage existing visual metadata that has already been generated andstored on data storage 1314. For example, an inline analytics framework1310 may be used to perform initial visual data processing in real-time(e.g., when visual data is first captured rather than in response to aquery), and an offline analytics framework 1312 may be used to performfurther visual data processing required for responding to searchqueries. Moreover, both the inline and offline analytics frameworks1310, 1312 may store their resulting visual metadata on data storage1314 for use in responding to subsequent visual search queries.Accordingly, in some cases, the visual processing dataflow 1308 for aparticular query 1302 may leverage existing visual metadata that hasalready been generated and stored on data storage 1314. In other cases,however, further processing may be required to respond to the query1302, and thus the visual processing dataflow 1308 may leverage theoffline analytics framework 1312 to perform additional processing. Ineither case, the visual processing pipeline or dataflow 1308 generatedby compiler 1304 is executed by the runtime environment in order togenerate a response to the visual query 1302.

FIG. 14 illustrates an example embodiment of a visual question answering(VQA) compiler 1400. In some embodiments, for example, compiler 1400 maybe used to compile VQA queries and/or user-defined vision functions(UVFs) 1402 into visual dataflow graphs 1417 that can be distributedacross and executed by the various fog nodes in a visual fogarchitecture.

In the illustrated embodiment, for example, UVFs 1402 are provided tothe compiler 1400 via a declarative API 1412. The compiler 1400 may thengenerate a graph of high-level vision operations 1415 that are requiredto execute the UVFs 1402, which may in turn be used to generate a visiondataflow graph 1417. In some embodiments, for example, the visiondataflow graph 1417 may be a directed acyclic graph (DAG) thatrepresents the visual processing pipeline required to execute theparticular UVFs 1402. Moreover, the compiler 1400 may use dataflowde-duplication to optimize the vision dataflow graph 1417, for example,by merging redundant portions of the dataflows of multiple UVFs 1402 toeliminate the redundancies.

In some embodiments, for example, compiler 1400 may generate the visiondataflow graph 1417 using information from the underlying vision modules1418 (e.g., hardware-specific information required for schedulingworkloads on heterogeneous hardware). The compiler 1400 may alsogenerate a number of database API calls to obtain visual data and/ormetadata required to execute the UVFs 1402. In various embodiments,these database API calls may either be part of, or separate from, thevision dataflow graph 1417. Moreover, in some embodiments, the compiler1400 may generate different results depending on the available visualmetadata.

In this manner, the resulting vision dataflow graph 1417 generated bycompiler 1400 can subsequently be executed by the runtime environment inorder to generate the results for responding to UVFs 1402.

Runtime

The visual fog paradigm envisions tens of thousands (or more)heterogeneous, camera-enabled edge devices distributed across theInternet and/or other large-scale networks, providing live sensing for amyriad of different visual processing applications, given taskparallelism and data parallelism. The scale, computational demands, andbandwidth needed for visual computing pipelines necessitates intelligentoffloading to distributed computing infrastructure, including the cloud,Internet gateway devices, and the edge devices themselves.

In some embodiments, for example, visual processing may be scheduled ordistributed across available fog devices based on various criteria,including device connectivity, device resource capabilities, deviceresource availability, workload type, privacy constraints, and so forth.Further, machine learning can be leveraged to optimize schedulingdecisions.

Workload deployment and/or migration can be implemented using ahot-pluggable runtime environment with universal plugin APIs. Forexample, conventional workload deployment/migration can be expensive, asit may require sending the runtime environment and toolchains to theassigned nodes. With hot-pluggable runtimes, however, workloads arehot-swappable (e.g., stop runtime, replace plugin, start runtime).

Moreover, a plugin or vision kernel repository can be used to facilitateworkload deployment. For example, a cloud-based or distributedrepository may be used to manage a collection of device andimplementation abstractions for each supported vision capability. Inthis manner, the repository can distribute the appropriate plugins orvision kernels to fog nodes based on their respective workloadassignments.

Incremental processing may be leveraged by a visual fog runtime tomaintain the state of any prior processing that has already beenperformed on visual data, enabling the results of the prior processingto be leveraged for subsequent visual processing and queries. Forexample, the results of any processing performed on visual data may berepresented as visual metadata, which may be stored for later use toavoid performing duplicative processing for subsequent visual queries.In this manner, when a visual query or UVF is received, the dataflowgenerated by a compiler may vary depending on the available metadatathat has already been generated and can be reused.

Metadata pre-provisioning can be used to reduce vision query latency bypre-processing visual data to complete common or frequent types ofprocessing in advance. In some embodiments, for example, a machinelearning model may be used to optimize the types of pre-processing thatis performed. For example, based on patterns of queries of the same typeor that involve similar types of processing, machine learning may beused to model the relationships of diverse queries, while also takingother modalities into account (e.g., weather, traffic). For example,metadata can be pre-provisioned by pre-scheduling certain types ofprocessing in advance based on the recent history of vision queries andUVFs. In this manner, patterns of common or similar vision workloads cantrigger pre-processing on newly captured visual data for those types ofworkloads to reduce query latency.

Similarly, stream prioritization or prefetching can be used to performlow-latency visual data loading or fetching based on historical trendsand/or workflows. For example, the vision processing history can be usedto prioritize certain data streams and/or pre-fetch data from memory fora particular application to improve query latency. Compared to metadatapre-provisioning, which involves expedited processing that is performedin advance, stream prioritization involves obtaining or moving visualdata to a location where it will likely be needed (e.g., from a camerato certain processing nodes).

Cached visual analytics can be used to optimize visual processing usingcached workflows, similar to incremental processing. For example, basedon cached information regarding particular visual streams that havealready been obtained and processed, along with the type of processingor workloads performed on those streams, subsequent vision processingdataflows may omit certain processing steps that have previously beenperformed and whose results have been cached. For example, a visualanalytics application involves a number of primitive vision operations.The volume of computation can be reduced, however, by caching visualanalytics results and reusing them for subsequent operations whenpossible. For example, when executing a visual analytics application,cached visual metadata resulting from prior processing can be searchedto avoid duplicative computation. In some embodiments, for example,cached visual analytics may be implemented as follows:

1. Each primitive vision operation is tagged or labeled using a cachetag;

2. For each instance or stream of visual data (e.g., each stored video),any corresponding visual metadata that has already been generated isstored in a metadata database or cache;

3. If there is a cache tag hit for a particular primitive visionoperation with respect to a particular instance or stream of visualdata, then the particular primitive vision operation can be omitted andinstead the existing visual metadata can be used; and

4. If there is a cache tag miss, however, the particular primitivevision operation is executed and the resulting metadata is cached in themetadata database for subsequent use.

Tensor factorization can also be used for distributed neural networkinferencing in order to address the overfitting problem. For example,representative weights of consecutive neural network layers can utilizetensor factorization to “smooth out” the model.

FIGS. 15 and 16 illustrate example embodiments of device-centricscheduling for visual fog computing. In some embodiments, for example,visual fog scheduling may depend on (1) device resource capacities, and(2) workload resource requirements. While the former remains constantand consistent, the latter can vary depending on a device's hardwarespecifications and software toolchains. For example, in someembodiments, there may be multiple implementations of a facialrecognition capability that are respectively optimized for differenttypes of hardware, such as CPUs, GPUs, FPGAs, ASICs, and so forth. Inthis manner, multiple implementations of a single vision capability canbe leveraged to create an opportunity for further optimization in visualfog computing.

Accordingly, in order to address the heterogeneity of devices withdifferent types of hardware and/or software, the illustrated embodimentsimplement device-centric scheduling using a vision capabilitiesrepository. In some embodiments, for example, the vision capabilitiesrepository may include multiple implementations of a particular visioncapability that are optimized for different hardware and/or softwareenvironments. In this manner, vision workloads can be scheduled ordistributed across fog devices based on their respective types ofresources and capabilities, along with per-resource telemetryinformation that identifies resource availability.

The basic principle is to abstract capabilities (e.g., face detection,gesture recognition) from their underlying kernels/implementations(e.g., SIFT-based implementations, deep neural network implementations).This type of abstraction provides the flexibility to deploy an arbitraryvision capability on a per-device basis. For example, usingresource-based scheduling, heterogeneous resource types of different fogdevices can be considered as a whole in order to determine the optimaltask-to-device mapping across the various fog devices, and also identifythe corresponding vision capability implementations that each deviceshould use for its assigned tasks. Moreover, resource telemetry can beused to monitor resource availability of fog devices on a per-resourcebasis (e.g., CPU, GPU, FPGA, ASIC, and so forth) to further facilitateintelligent scheduling decisions. Further, the vision capabilityrepository hosts collections of implementations of different visioncapabilities, and may also provide a request-response service thatallows a device to request an available implementation of a particularvision capability.

In this manner, device-centric scheduling can be used to improveend-to-end (E2E) performance (e.g., latency and bandwidth efficiency)and scalability for visual fog computing.

FIG. 15 illustrates an example architecture 1500 for implementingdevice-centric scheduling in a visual computing system. In theillustrated embodiment, for example, visual computing architecture 1500includes users 1502, scheduling server 1504, vision kernel repository1506, and various types of fog devices 1510. A fog device 1510, forexample, can include any device ranging from the edge of a network tothe cloud, inclusively. In the illustrated embodiment, for example, fogdevices 1510 include cameras 1510 a, gateways 1510 b, and cloud servers1510 c.

In some embodiments, users 1502 may submit search queries for visualdata captured by cameras 1510 a. Moreover, in order to respond to thosequeries efficiently, scheduling server 1504 may schedule or distributevision processing workloads across the various fog devices 1510. In someembodiments, for example, scheduling server 1504 may perform intelligentscheduling decisions based on various criteria, such as the types ofresources in the fog (e.g., the heterogeneous types of resources of thevarious fog devices 1510), resource telemetry information (e.g., theavailability of fog resources on a per-resource-type basis), and theimplementations of vision capabilities that are available in the visioncapability repository 1506.

An example embodiment of the scheduling process, for example, isdescribed below in connection with FIG. 16.

FIG. 16 illustrates a flowchart 1600 for an example embodiment ofdevice-centric scheduling in a visual computing system. In someembodiments, for example, flowchart 1600 may be implemented using visualcomputing architecture 1500 of FIG. 15.

The flowchart may begin at block 1602 by collecting the available visioncapability implementations. In some embodiments, for example, thescheduling server continuously synchronizes the collection of availableimplementations of vision capabilities from the vision capabilityrepository.

The flowchart may then proceed to block 1604 to collect the resourcetelemetry of fog devices. In some embodiments, for example, thescheduling server may collect the resource availability of all fogdevices on a per-resource-type basis. For example, the scheduling servermay collect information regarding the resource availability of CPUs,GPUs, FPGAs, ASICs, and/or any other resource type across all fogdevices.

In this manner, based on the available vision capability implementationscollected at block 1602, and the resource telemetry informationcollected at block 1604, the scheduling server can subsequently schedulevision workloads based on the optimal task-to-device mapping in thevisual fog paradigm.

For example, the flowchart may then proceed to block 1606 to determinewhether a new vision workload has been received from a user. In someembodiments, for example, a user may submit a new visual query, whichmay require a new vision workload to be scheduled or distributed acrossthe fog devices.

If it is determined at block 1606 that a new vision workload has NOTbeen received, the flowchart may then proceed back to block 1602 tocontinue synchronizing the available vision capability implementationsand collecting resource telemetry information until a new visionworkload is received.

If it is determined at block 1606 that a new vision workload has beenreceived, the flowchart may then proceed to block 1608 to re-scheduleall pending workloads. In some embodiments, for example, receiving a newvision workload for a user may trigger the scheduling server tore-schedule all pending workloads to ensure the collective workloads aredistributed across the fog devices in the most efficient manner possible(e.g., based on the optimal task-to-device mapping).

In some embodiments, for example, scheduling may be performed based onvarious criteria, such as the types of fog resources that are available,telemetry information for those resources, and the vision capabilityimplementations that are available for those fog resources.

In some embodiments, for example, a schedule that adheres to theconstraints of multiple resource types can be determined using integerlinear programming (ILP). Integer linear programming (ILP) is amathematical optimization or feasibility technique for solving oroptimizing a mathematical model represented by linear relationships. Inparticular, ILP can be used to optimize a linear objective function,subject to additional linear equality and linear inequality constraints.As an example, an ILP problem can be expressed as follows:

$\begin{matrix}{{{minimize}\text{:}}\;} & {{c^{T}x}\mspace{76mu}} & {( {{objective}\mspace{14mu}{term}} )\mspace{65mu}} \\{{subject}\mspace{14mu}{to}\text{:}} & {{{Ax} \leq b}\mspace{45mu}} & ( {{inequality}\mspace{14mu}{constraint}} ) \\\; & {{{Cx} = d}\mspace{205mu}} & {( {{equality}\mspace{14mu}{constraint}} )\mspace{20mu}} \\{{{and}\text{:}}\mspace{65mu}} & {x \in \{ {0,1} \}^{K}} & {{( {{binary}\mspace{14mu}{constraint}} ).}\mspace{31mu}}\end{matrix}$

Moreover, this ILP model can be used to determine an optimal schedule fthat satisfies a specified objective (e.g., total network utilization),while also adhering to other additional constraints (e.g., deviceresource constraints). In the above ILP model, for example, x presentsthe collection of possible schedules f, K is the length of x, theobjective term presents a scheduling objective to be minimized (e.g.,total network utilization), and the inequality/equality constraintspresent any additional constraints (e.g., device, resource, network,mapping, and/or privacy constraints). A device resource constraint, forexample, can be presented as an inequality constraint of the ILP model.For example, in order to take into account constraints of multipleresource types, they can be expended into multiple inequalities in theform of Ax≤b in the ILP model above.

Accordingly, based on the scheduling decisions, the scheduling serverassigns each fog device zero or more tasks. In some embodiments, forexample, a task may be specified in a tuple of the form t=(p, r), wherep denotes the vision capability and r denotes resource type (e.g.,p=face detection, r=Movidius processor).

The flowchart may then proceed to block 1610 to determine if an updatedworkload schedule is available. For example, after a new vision workloadis received and the pending workloads are re-scheduled, the schedulingserver may have an updated or improved workload schedule that needs tobe distributed to the fog devices. In some embodiments, however, thescheduling server may only update the workload schedule if the newlygenerated schedule is better or more efficient than the current workloadschedule.

If it is determined at block 1610 that the workload schedule has NOTbeen updated, the flowchart may then proceed back to block 1602 tocontinue synchronizing the available vision capability implementationsand collecting resource telemetry until the current workload schedule iseventually updated.

However, if it is determined at block 1610 that an updated workloadschedule is available, the flowchart may then proceed to block 1612 topush the updated schedule to all fog devices.

The flowchart may then proceed to block 1614 to receive requests fromfog devices for vision capability implementations. For example, each fogdevice may query the vision capability repository to requestimplementations of vision capabilities for the tasks assigned to theparticular fog device. In some embodiments, for example, the requestfrom a particular fog device may identify each of its assigned tasks t.

The flowchart may then proceed to block 1616 to identify the appropriatevision capability implementations for each fog device. In someembodiments, for example, the vision capability repository may be adictionary of key-value pairs in the form of (task t, implementation i),where an implementation i can be distributed in various forms (e.g., adynamic linking library in C/C++). Accordingly, based on the task(s) tspecified in the request from a particular fog device, the visioncapability repository identifies the corresponding implementation(s) ifor that fog device. In some embodiments, for example, the visioncapability repository identifies the optimal implementation of eachvision capability requested by a fog device based on the availableresources of that fog device.

The flowchart may then proceed to block 1618 to distribute theidentified vision capability implementations to each fog device. In thismanner, each fog device can then perform its assigned tasks using theappropriate vision capability implementations.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 1602 to continue scheduling vision workloads.

FIG. 17 illustrates an example embodiment of a runtime processingpipeline 1700 for a visual fog architecture. In the illustratedembodiment, for example, a raw stream of visual data 1701 (e.g., videoor images) captured by cameras or visual sensors in a visual fogarchitecture is provided as input to a stream ingress framework 1702.The stream ingress framework 1702 decodes the raw stream of visual data1701, and a decoded stream 1703 is then provided as input to adistributed pre-processing framework 1704. The distributedpre-processing framework 1704 then performs some preliminary processingusing certain fog resources at the network edge (e.g., near the camerasor sensors that captured the visual data), such as data pre-processing,filtering, and/or aggregation. The resulting filtered stream 1705 maythen be stored in data storage 1706 for subsequent use in responding tovisual search queries and/or user-defined vision functions (UVFs) 1709from end-users.

For example, end-users may subsequently submit visual search queriesand/or user-defined vision functions (UVFs) 1709 associated with thevisual data captured by the visual fog system. Accordingly, the UVFs1709 are provided to a UVF compiler 1710, which compiles the UVFs 1709into a vision dataflow graph 1711 that can be used to execute the UVFs.For example, the vision dataflow graph 1711 is provided to a distributedUVF execution framework 1712, which distributes or schedules workloadsassociated with the vision dataflow graph 1711 across the available fognodes in the visual fog architecture.

After the workloads finish executing, the distributed UVF executionframework 1712 generates an output 1713 resulting from execution of theUVFs 1709. For example, the output 1713 may include, or may be derivedfrom, a filtered stream of visual data and/or metadata 1707 generated byexecution of the UVFs 1709. Moreover, in some embodiments, the resultingstream of visual data and/or metadata 1707 may then be stored in datastorage 1706 for responding to subsequent visual search queries or UVFs.

Storage

As the volume of visual data generated in the real-world continues togrow, it is becoming increasingly common for visual data to be processedautomatically by computers rather than manually reviewed by humans. Dueto the increasing volume of visual data, however, data access has becomea bottleneck in visual data processing, as existing visual data storageapproaches suffer from various deficiencies.

To illustrate, image classification is a common visual data operationthat uses a neural network to identify the contents of an image. Forexample, in machine learning, a convolutional neural network (CNN) is atype of feed-forward artificial neural network where the input isgenerally assumed to be an image. CNNs are commonly used for imageclassification, where the goal is to determine the contents of an imagewith some level of confidence. For example, a CNN is first trained for aspecific classification task using a set of images whose object classesor features have been labeled, and the CNN can then be used to determinethe probability of whether other images contain the respective objectclasses.

Visual data (e.g., images, video) must first be loaded from a storagesystem before it can be processed by a CNN. In the past, the data accesslatency has typically been less than the CNN vision processing latency,allowing the data access to be performed during the CNN processing.However, as hardware and software optimizations continue to improve theperformance of CNN vision processing algorithms, the data access latencyof existing solutions has become the bottleneck. Moreover, existingsolutions typically store visual data in its original format rather thana format designed to aid with visual data processing, which furtherhinders performance.

Existing solutions are also unable to efficiently search visual data.For example, given a large data set (e.g., millions of images), theability to efficiently identify a subset of relevant images using aquery is important. The output of a CNN used for image classificationtypically includes a vector of values corresponding to the probabilityof various objects existing in an image. However, existing solutionstypically use this information for the task at hand and then discard it,requiring the processing to be repeated for subsequent use. For example,a CNN used to process an image with a dog and a cat may provide aprobability for both, but if the goal was to find images with dogs, theinformation about cats is typically lost or discarded, thus preventingfuture use. In this manner, a subsequent search for images that containcats would typically require the CNN to be run again on each image.

Accordingly, FIG. 18 illustrates an example embodiment of a visual datastorage architecture 1800 designed to provide efficient access to visualdata and eliminate the deficiencies of existing storage solutions usedfor visual data processing. In particular, storage architecture 1800provides efficient metadata storage for searching visual data, as wellas analysis-friendly formats for storing visual data.

In the illustrated embodiment, for example, storage architecture 1800includes a request server 1802 for receiving visual search queries froma client API 1801, a metadata database 1804, a visual compute library1806, and a persistent data storage 1810, as explained further below.

In some embodiments, for example, storage architecture 1800 may providea unified API 1801 for visual data access (e.g., for both visual dataand metadata). For example, visual data is commonly stored directly asfiles or in various types of databases (e.g., key-value, relational,and/or graph databases). Visual metadata is typically stored indatabases, for example, while images and videos are typically stored asfiles. Moreover, different types of file systems and databases provideAPI functions in various programming and/or query languages in order toenable users to access and store data. Accordingly, in some embodiments,visual storage architecture 1800 may be implemented with a unified API(e.g., JSON-based) that supports multi-modal queries for retrieving anytype of visual data from any storage source. In some embodiments, forexample, the unified API could be used to retrieve and/or combine visualmetadata and the original visual data from different storage locations.The unified API may also allow certain types of processing to beperformed on visual data before it is returned to the requesting user.Further, the unified API may allow users to explicitly recognize visualentities such as images, feature vectors, and videos, and may simplifyaccess to those visual entities based on their relationship with eachother and with other entities associated with a particular visionapplication.

Moreover, in some embodiments, a multi-tier lazy data storage approachmay be used to store visual data more efficiently (e.g., using long- orshort-term storage in different portions of the distributededge-to-cloud network). For example, multiple storage tiers may be usedto store visual data in different locations and for varying amounts oftime based on the type or importance of the visual data. In someembodiments, for example, video cameras may store all video capturedwithin the past day, gateways may store video with motion activitieswithin the past week, and the cloud may store video associated withcertain significant events within the past year.

Similarly, intelligent placement and aging of visual data across thestorage tiers may further improve the data storage efficiency (e.g.,determining where to store the visual data within the distributededge-to-cloud system, when the data should be moved from hot to warm tocold storage, and so forth). For example, visual data and metadata canbe distinguished and segregated based on data access patterns. Moreover,analysis friendly storage formats can be used to enable data to be readfaster when needed for vision processing. These various data formats maybe used to form the hot, warm, and cold tiers of data that can be mappedto various heterogeneous memory and storage technologies, based on theintended use and lifetime of the data. For example, storage tiers can beused to represent hot, cold, and optionally warm data. Hot data isaccessed frequently; warm data is accessed occasionally; and cold datais accessed rarely (if ever). Accordingly, cold data may be stored onslower hardware since low access latency for retrieval of the data isless important. In this manner, intelligent decisions can be used todetermine when and which portions of visual data should remain in thehot tiers and when it should be migrated to colder tiers, and whichstorage format should be used. For example, regions of interest mayremain in hot storage in the analysis friendly format much longer thanthe entire image/video.

Metadata database 1804 is used to store metadata in a manner thatfacilitates efficient searches of visual data. For example, whenperforming image classification using a CNN, the resulting image-objectrelationships or probabilities can be stored as metadata, and themetadata can be used for subsequent searches of the images, thuseliminating the need to repeatedly process the images for each search.For example, FIG. 19 illustrates an example of a vision processingpipeline 1900 that leverages metadata for searching visual data. In theillustrated example, a stream of incoming visual data is received from anetwork or file system at block 1902, vision processing is performed onthe visual data to derive metadata (e.g., using a CNN) at block 1904,the metadata is stored at block 1906, search queries for relevant visualdata are received at block 1908, and the search queries are thensatisfied using either the metadata obtained at block 1906 or additionalvision processing performed at block 1904.

In some embodiments, storage architecture 1800 may store visual metadataas a property graph to identify relationships between visual data, suchas images that contain the same object or person, images taken in thesame location, and so forth. For example, FIGS. 20 and 21 illustrateexamples of representing visual metadata using a property graph. In thismanner, visual metadata can be easily searched to identify theserelationships, thus enabling flexible search queries such as “find allimages taken at location Y that contain person A.”

Moreover, in some embodiments, metadata database 1804 of storagearchitecture 1800 may be implemented as a persistent memory graphdatabase (PMGD) to enable visual metadata to be searched moreefficiently. For example, using persistent memory (PM) technology, agraph database containing the visual metadata can be stored bothin-memory and persistently. In this manner, a persistent memory graphdatabase (PMGD) can be designed to leverage a memory hierarchy with datastructures and transactional semantics that work with the PM cachingarchitecture, reduce write requests (addressing PM's lower writebandwidth compared to DRAM), and reduce the number of flushes and memorycommits. This approach enables a graph database of visual metadata to besearched efficiently to identify relevant visual data.

Further, feature vector storage optimizations may be used to achievefast searching of visual metadata. For example, feature vectors can begenerated by various vision algorithms to identify regions or featuresof interest in visual data (e.g., faces, people, objects), and they aretypically represented as vectors of n-dimensional floating-point values.Finding the nearest neighbor for a given feature vector is a commonoperation that is computationally expensive, especially at the cloudscale due to billions of potential feature vectors (e.g., a featurevector for each interesting region of each image or video frame).Accordingly, in some embodiments, feature vectors may be represented andstored as visual metadata using an efficient format. For example, visualmetadata may be stored using an analysis-friendly array format thatindicates where the feature vectors reside, and an index may be built oninteresting dimensions within the metadata storage to narrow the searchspace.

Storage architecture 1800 also includes a separate data storage 1810 forstoring the visual data itself, such as images or videos. Segregatingthe metadata and visual data in this manner enables each type of data tobe mapped to the most suitable hardware in a heterogeneous system, thusproviding flexibility for the request server 1802 to identify the mostefficient way to handle a visual data request.

Moreover, storage architecture 1800 is also capable of storing visualdata on data storage 1810 using an analytic image format designed to aidin visual processing. In the illustrated embodiment, for example, visualcompute library (VCL) 1806 of storage architecture 1800 is designed tohandle processing on analytic image formats 1807 in addition totraditional formats 1808. For example, visual compute library 1806 canimplement an analytic image format 1807 using an array-based datamanagement system such as TileDB, as described further with respect toFIG. 22. The analytic image format 1807 provides fast access to imagedata and regions of interest within an image. Moreover, since theanalytic image format 1807 stores image data as an array, the analyticimage format 1807 enables visual compute library 1806 to performcomputations directly on the array of image data. Visual compute library1806 can also convert images between the analytic image format 1807 andtraditional image formats 1808 (e.g., JPEG and PNG). Similarly, videosmay be stored using a machine-friendly video format designed tofacilitate machine-based analysis. For example, videos are typicallyencoded, compressed, and stored under the assumption that they will beconsumed by humans. That assumption is often leveraged for videoencoding by eliminating information that human eyes and brains cannotprocess. Videos intended for machine-based processing, however, maybenefit from alternative storage methods designed to speed up the timerequired to retrieve full images or regions of interest within a videoor video frame, and even enhance the accuracy of machine-learning videoprocessing mechanisms.

FIG. 22 illustrates an example embodiment of an analytic image format2200 designed to aid in visual data processing. In some embodiments, forexample, storage architecture 1800 may use analytic image format 2200 tostore images in a format that facilitates visual data processing andanalysis.

Deep learning neural networks, such as CNNs, are frequently used forimage processing, including object/edge detection, segmentation, andclassification, among other examples. Images are typically read fromdisk during both training and inferencing, for example, using backgroundthreads to pre-fetch images from disk and overlap the disk fetch anddecode times with the other compute threads. However, compute cycles maystill be wasted reading the images from disk and decompressing/decodingthe images to prepare them for processing, thus reducing the overallthroughput (e.g., images/second) of an image processing system.

Moreover, traditional lossy image formats (e.g., JPEG) are designed tocompress image data by discarding high-frequency information that is notperceptible by humans. While the discarded information may bemeaningless to humans, however, it can improve the accuracy andperformance of deep learning neural networks used for image processing.

For example, images can be compressed either in a lossless or lossymanner. Lossless image compression preserves all the information in theimage, while lossy compression takes advantage of visual perception andstatistical properties to achieve better compression rates, but resultsin some data being lost. The JPEG compression algorithm is a commonlyused lossy algorithm that is often used for images on the web. The JPEGalgorithm is based on discrete cosine transforms (DCT), and discardshigh-frequency details that are not perceptible to the human eye, whichresults in much smaller image file sizes. However, in cases where exactimage reproduction is required, or when the image will be editedmultiple times, lossless compression is preferred. For example, PNG isan image file format that supports lossless compression using a bitmapimage. With PNG, images are transformed using a filter type on aper-line basis, and then compressed using the DEFLATE algorithm. Thereare numerous other image formats with similar technologies behind themthat are suitable for different applications and use cases. While atraditional lossless image format (e.g., PNG) could be used to retainall image data for image processing purposes, that comes at the cost ofa lower compression rate.

Further, images stored using traditional formats (e.g., JPEG and PNG)must be converted into an internal array format before any processingcan begin. For example, before any operations can be performed on imagesstored using traditional formats, the entire image file must be readfrom disk and decoded into an internal array format. In analytics,however, operations such as resizing and cropping are often performedbefore any sort of learning or understanding happens, thus renderingtraditional image formats inefficient for image processing andanalytics.

Accordingly, traditional image formats (e.g., JPEG and PNG) are designedfor human consumption, and performing operations on them is oftentime-consuming and inefficient. Moreover, lossy image formats (e.g.,JPEG) discard information that may be useful in machine learning, andthus are not well-suited for image processing. Moreover, while existingdatabase management systems could be used to store images, they are notdesigned for image data and thus do not store image data efficiently.

The analytic image format 2200 of FIG. 22 is designed to aid in imageprocessing and alleviate the deficiencies of existing image formats. Forexample, image format 2200 is implemented using an array-based datastorage format that is lossless and eliminates the expensive decodingprocess that is required for processing traditional image formats. Insome embodiments, for example, analytic image format 2200 could beimplemented using an array-based data storage manager such as TileDB.TileDB is a data management system designed for efficiently managinglarge volumes of scientific data represented using arrays. While TileDBis not specific to images, it is designed to provide fast access toarray-based data. Accordingly, in some embodiments, image format 2200can be implemented using TileDB to achieve the performance boost ofTileDB for image processing purposes.

In some embodiments, for example, analytic image format 2200 can beimplemented by defining how the pixel data of an image is stored andaccessed in an array-based format (e.g., using an array-based datastorage manager such as TileDB). In this manner, image format 2200enables efficiency in processing large images, which reduces the overalltime for image analytics. As visual understanding algorithms get fasterand the hardware to perform the algorithms gets better, the time toretrieve and process the images is becoming more and more significant.However, by using analytic image format 2200, storage and retrieval ofimages does not become a bottleneck in the visual processing pipeline.

For example, analytic image format 2200 allows an image to be stored asa lossless compressed array of pixel values. Accordingly, when imagedata is needed for processing, the image data does not need to bedecoded before being processed, as required for traditional imageformats. This improves the speed at which data is retrieved and madeusable, yet still provides some level of compression. While thisapproach requires images to be written to the analytic image format 2200prior to training or inference, the additional write overhead isminimal.

Moreover, because TileDB outperforms many array database managers forboth sparse and dense data access, it is an ideal choice forimplementing analytic image format 2200. In other embodiments, however,analytic image format 2200 can be implemented using any other type ofarray-based data manager or data format. The use of a fast, enhancedarray storage system such as TileDB enables image format 2200 toeliminate slow reads of images from disk, and remove the in-loopconversion of traditional image formats to arrays.

Image format 2200 is also beneficial in applications where subarrayaccesses are common, such as accessing regions of interest in an image.For example, an array data manager such as TileDB can be used to improvethe speed of common operations that are needed for image analytics, suchas resize and crop, by enabling fast subarray accesses.

FIG. 22 illustrates the process of converting an image into an analyticimage format 2200 using an array-based data manager such as TileDB. Inthe illustrated example, the original image is first received 2202 andis then divided into a plurality of tiles 2204 using an optimal tilesize, and the tiles are then compressed and written to memory on aper-tile basis 2206 using an array-based storage format.

In some embodiments, the optimal tile size for analytic operations canbe dynamically determined for each image. For example, in order todetermine the optimal tile size for a particular image, a random portionof the image may be selected and then processed using different tilesizes and compression algorithms in order to determine the ideal tilesize and compression for that image. Moreover, since image processingoperations are often postponed until the data is actually needed, thereis a period of time available to carry out the experimentation withoutimpacting performance.

An image that does not fit perfectly into tiles of the selected tilesize will have partially empty tiles that are padded with emptycharacters, as depicted in FIG. 22. In this manner, the original size ofthe image may be stored as metadata (e.g., height, width, and number ofchannels), and when the image is subsequently read from storage, themetadata can be checked to determine the actual dimensions of the imageto avoid reading the empty characters or padding.

For high-resolution images, image format 2200 improves the speed ofcommon operations such as reading and writing, as well as the speed ofoperations used in image analytics, such as cropping and resizing. Forexample, storing images using image format 2200 improves readperformance, as the images are compressed but not encoded, and thus donot need to be decoded when they are read from the file system. Inaddition, image format 2200 enables fast access to subarrays of imagepixels, making cropping a simple matter of reading a particular subarrayrather than reading the entire image and then cropping it to theappropriate size.

For example, FIG. 23 illustrates a graph 2300 comparing the performanceof analytic image format 2200 from FIG. 22 with the PNG image format,which is a traditional lossless image format. As shown by FIG. 23, theanalytic image format provides better performance than PNG for writes,reads, crops, and resizes. The largest improvement is seen in cropping,as the analytic image format allows only the pertinent information to beread from the file, rather than reading the entire image file and thencropping to the desired size. Accordingly, the performance improvementfor common data access and analytic operations demonstrates thatanalytic image format 2200 is highly beneficial for image processingpurposes.

FIG. 50 illustrates an example write processing flow 5000 fortraditional and analytic image formats. In the illustrated processingflow 5000, for example, raw pixel data 5002 can be written to disk 5010using either a traditional image format or an analytic image format. Thetop path of processing flow 5000 illustrates the flow for writingtraditional image formats (e.g., PNG), while the bottom path illustratesthe flow for writing analytic image formats.

With respect to traditional image formats, for example, raw pixel data5002 is encoded 5004, compressed 5006, and then stored 5010. Withrespect to analytic image formats, however, raw pixel data 5002 iscompressed 5008 and then stored 5010, but the encoding step is omitted.While the resulting analytic image format may result in a larger filesize on disk, the latency of data access operations (e.g., writes) andother image operations may be reduced.

Moreover, the read processing flow for traditional and analytic imageformats may be implemented as the reverse of the write processing flow5000. For example, with respect to traditional image formats, theencoded/compressed data is read from disk, decompressed, and thendecoded into the original image. With respect to analytic image formats,the compressed data is read from disk and then decompressed into theoriginal image, but the decoding step is omitted since the encoding stepwas omitted during the write processing flow 5000.

TABLE 1 illustrates an example analytic image format schema. In someembodiments, for example, the analytic image format schema of TABLE 1could be implemented using an array-based database manager (e.g.,TileDB) to store images as dense arrays.

TABLE 1 example analytic image format PARAMETER TYPE EXAMPLE VALUE cellorder fixed row major tile order fixed row major number of dimensionsfixed 2 dimension names fixed “height”, “width” number of attributesfixed 1 compression fixed LZ4 array height variable 3534 array widthvariable 5299 domain variable [0, 3533, 0, 5298] tile height variable 589 tile width variable  757

The schema of TABLE 1 specifies parameters about the array that can beused to arrange the image data. Moreover, some parameters of theanalytic image format are fixed, while others are determined on aper-image basis. For example, images have only two dimensions, a heightand a width, thus fixing the number of dimensions as well as the namesof the dimensions. The number of attributes is set to one, which meanseach cell holds the blue, green, and red (BGR) values for thecorresponding pixel. All three values are generally read together, as apixel is defined by all three values. In other embodiments, however, thecolor values may be stored separately. The intra-tile and array-leveltile ordering is fixed to be row major. Row major order means that datais written and read from left to right in rows within a tile, and tilesare written and read in the same manner. This information allows thearray database to efficiently perform subarray reads.

The dimensions and domain of the array depend on the resolution of theoriginal image and therefore are calculated dynamically on a per-imagebasis. Since images often do not have an evenly divisible number ofpixels in one or both dimensions, this occasionally results in thedimensions of an array not matching the original resolution of theimage. This is reflected in TABLE 1, where the array height is one pixellarger than the image height. To make up the difference between an imagedimension and an array domain, the image is padded with emptycharacters. An example of this can be seen in FIG. 22, where the whitespace within certain tiles corresponds to empty characters. In theactual array, the size of the array domain is increased by a singlepixel when needed. The original size of the image (height, width, andnumber of channels) is stored as metadata by default. When an image inthe analytic format is read, the metadata is read first in order todetermine the dimensions of the image, thus avoiding reading the emptycharacters.

Tile extents depend on the array dimensions and are calculated once thearray dimensions are known. All tiles have the same height and width.The optimal number of tiles may vary based on image content andresolution, and thus in some embodiments, the optimal number of tilesmay be determined on a per-image basis. For example, in order todetermine the best tile size, a portion of the image may be randomlyselected and tested using different tile sizes and compressionalgorithms to determine the best combination for that image. Since alloperations are postponed until the data is actually needed, there is aperiod of time to carry out the experimentation that does not affect theperformance. In other embodiments, however, a predefined minimum numberof tiles per dimension (e.g., 4 tiles per dimension) may be used as abasis to determine tile height and width.

The compression algorithm used to compress the analytic image data has afixed default (e.g., the LZ4 compression algorithm), but othercompression algorithms can be set manually.

FIG. 51 illustrates an example embodiment of a visual compute library(VCL) 5100 for traditional and analytic image formats. For example, VCL5100 provides an interface through which a user can interact with theanalytic image format as well as traditional image formats.

When a user creates an analytic image using VCL 5100, the analytic imageschema is automatically set using the parameters described above inTABLE 1. VCL 5100 then creates a layer of abstraction with functioncalls of TileDB 5102 (e.g., the array-database manager used in theillustrated embodiment) combined with specialized transformationoperations to provide an interface to the analytic image. VCL 5100 alsoextends the abstraction layer to OpenCV 5104, providing support for PNGand JPEG image formats. VCL 5100 uses OpenCV 5104 to perform both I/Oand transformation operations on images that are stored in either PNG orJPEG format. For images stored in the analytic format, VCL 5100 handlesthe transformation operations and uses TileDB 5102 for I/O operations.

To initially store an image in the analytic format, the raw pixel dataof an image is passed to VCL 5100 in some manner (e.g., as a path to aPNG or JPEG file stored on disk, an OpenCV matrix, a buffer of encodedpixel data, a buffer of raw pixel data, and so forth). This data isconverted to a raw pixel buffer in order to write to the analyticformat. Since the TileDB array schema for images has already been set atthis point (e.g., using the parameters of TABLE 1), the TileDB functionscan be used to write the data to disk.

Reading an image in the analytic format requires the metadata to be readfirst to determine the original image resolution. This ensures that onlyimage data is read and that empty characters are ignored. The rawanalytic-format or TileDB data is read into a buffer, keeping the datain the order in which it was written, which is referred to as “tileorder” (e.g., as illustrated in FIG. 52). This is because if the datanever needs to be returned to the user (e.g., if the user just wants tomanipulate it and write it out again), it is faster to use the tileorder buffer. In cases where the data is to be returned to the user,however, the buffer is re-ordered into image order, which results in abuffer that has each row of the image sequentially (e.g., as illustratedin FIG. 52). Image order, for example, is typically expected by otherprograms such as OpenCV 5104.

Crop, another frequently used operation in image processing, is used toretrieve a region of interest within an image for processing. Ratherthan reading the entire image and then selecting a sub-region (as isrequired for traditional image formats), the analytic or TileDB cropfunction uses the crop parameters to specify a subarray of the analyticimage data. The subarray is then the only portion of the image that isread.

Resize, another frequently used operation in image processing, is usedto resize the dimensions of an image (e.g., to either a smaller orlarger size). The TileDB resize occurs after the image has been read,but while the data is still in tile order. VCL 5100 implements a versionof resize for TileDB that uses a bilinear interpolation, following theOpenCV default. For example, in a linear interpolation, a new value iscalculated based on two points; bilinear interpolation does this in twodifferent directions and then takes a linear interpolation of theresults. These points are identified by (row, column) in the originalimage. Given the data is in tile order, it is necessary to identifywhich tile each point is part of in order to locate the value of thatpoint in the buffer. The resulting resized image buffer is in imageorder, although other approaches may be used to keep it in tile order.

Compression/Compressive Learning

The performance of large-scale visual processing systems can be improvedusing efficient compression algorithms and techniques for storing andprocessing visual data. The compression approaches of existing visualprocessing solutions, however, suffer from various deficiencies. Forexample, existing solutions require visual data to be fully decompressedbefore any processing can be performed (e.g., using deep learning neuralnetworks). Moreover, existing solutions typically compress and storeimages individually, thus failing to leverage the potential compressivebenefits of collections of similar or related images with redundantvisual data.

Accordingly, this disclosure presents various embodiments forcompressing and processing visual data more efficiently. In someembodiments, for example, neural networks can be designed to operate oncompressed visual data directly, thus eliminating the need to decompressvisual data before it can be processed. Moreover, context-awarecompression techniques can be used to compress visual data and/or visualmetadata more efficiently. For example, context-aware compression can beused to compress distinct instances of redundant visual data moreefficiently, such as a group of images taken close in time, at the samelocation, and/or of the same object. Similarly, context-awarecompression can be used to compress visual metadata more efficiently(e.g., using a context-aware lossless compression codec). In someembodiments, for example, visual metadata could be compressed bypre-training a convolutional neural network (CNN) to classify visualmetadata, replacing long strings of visual metadata with shorter symbols(e.g., pre-defined human codes), performing multi-scale de-duplicationon the visual metadata, and finally compressing the resulting visualmetadata using a compression algorithm (e.g., the LZ77 losslesscompression algorithm or another similar alternative).

FIGS. 24A-C illustrate an example embodiment of a multi-domain cascadeconvolutional neural network (CNN) 2400.

In distributed visual analytics systems, image and video is oftencompressed before transmission (e.g., from the pixel domain to acompressed domain), and subsequently decompressed after transmission(e.g., back to the pixel domain) before any processing can be performed,such as deep learning using neural networks. As an example, image andvideo captured by edge devices may be compressed and transmitted to thecloud, and then decompressed by the cloud before any further processingbegins.

This approach suffers from various disadvantages. First, extracomputation is required to fully decompress the visual data before itcan be processed, thus significantly increasing the total processingtime (e.g., by up to 100% in some cases). For example, before processingcan be performed, the visual data must be fully decompressed back to thepixel domain using hardware or software decoding. Accordingly, giventhat not all processors include built-in video decompressionaccelerators, decompression may incur an additional cost for videoanalytics.

Next, extra bandwidth is required to transmit the decompressed databetween separate processing components (e.g., between a decompressionengine and an analysis engine), thus significantly increasing bandwidthusage (e.g., by up to 20 times in some cases).

Moreover, the requirement to fully decompress visual data prior toprocessing precludes the ability to leverage a fully distributed neuralnetwork in the edge-to-cloud sense. For example, the use of distributedanalytics to process visual data exclusively in the pixel domainrequires the visual data to be analyzed at multiple scales.

Further, relying on the cloud to perform processing on visual datacaptured by edge devices often results in wasted transmission bandwidth,as many images or videos transmitted from the edge to the cloud may notcontain any objects or features of interest. In many cases, for example,it could be possible to perform object detection and classificationcloser to the network edge (e.g., near the sensors that capture thevisual data) using lower complexity analytics algorithms, potentiallysaving the transmission cost of insignificant or unimportant data.

Accordingly, FIGS. 24A-C illustrate an example embodiment of amulti-domain cascade CNN 2400 that can be used to process visual data inthe compressed and pixel domains, thus eliminating the requirement todecompress visual data before it can be processed. In this manner,multi-domain cascade CNN 2400 can be used to perform distributed visualanalytics in a visual fog system using compressed domain data as input.

In some embodiments, for example, multi-domain cascade CNN 2400 may be acascaded CNN that includes multiple decision stages. For example, in afirst or early decision stage, a subset of the compressed domain visualdata or features may be used (e.g., motion vectors) to attempt togenerate an early decision. If the visual data cannot be detected orclassified in the early stage, additional compressed domain data (e.g.,motion prediction residuals) may be provided as input to a subsequent orlate decision stage. Finally, for improved accuracy and/or in the eventthe late decision stage is unsuccessful, the visual data may be fullydecompressed and a final decision stage may be performed using thedecompressed visual data.

In the illustrated embodiment, for example, CNN 2400 includes an earlydecision stage (illustrated in FIG. 24A), a late decision stage(illustrated in FIG. 24B), and a final decision stage (illustrated inFIG. 24C). Moreover, CNN 2400 is designed to process compressed visualdata 2402 as input (e.g., video sequence data compressed with amotion-compensated predictive coding scheme such as H.264).

In some embodiments, for example, compressed visual data 2402 providedas input to CNN 2400 may first be partially decoded to separate andextract different syntax elements (e.g., motion vectors, macroblock (MB)coding modes, quantized prediction residuals), thus producing a subsetof partial compression data 2404.

As shown in FIG. 24A, in the early decision stage, the partialcompression data 2404 (e.g., motion vectors) is provided as input to afirst stage CNN 2405 a to attempt to identify an early decision 2406. Insome embodiments, the CNN processing may then terminate if an earlydecision can be made. For example, in some embodiments, the earlydecision stage may be performed by a fog or edge node near the sensorthat captured the visual data. Accordingly, if an early decision can bemade, it may be unnecessary to transmit additional visual data toanother node (e.g., in the cloud) for a subsequent processing stage,thus saving bandwidth and/or resources (e.g., energy) that wouldotherwise be required for the later stage. For example, assuming thegoal is to detect moving pedestrians using traffic cameras, if there isno motion detected, there likely are no moving objects. Accordingly, anearly decision can be made, and any further transmission or processingof the visual data can be aborted. In other embodiments, however, thesubsequent CNN processing stages of CNN 2400 may still be performed evenif an early decision can be made. Moreover, the complexity of the firststage CNN 2405 a may vary based on different use cases, resourceavailability, and so forth.

If the early decision stage is unable to detect or classify the partialcompression data 2404 using the first stage CNN 2405 a, CNN 2400 mayproceed to a late decision stage, as shown in FIG. 24B. In the latedecision stage of FIG. 24B, for example, additional compression data2410 (e.g., motion prediction residuals) is evaluated using a secondstage CNN 2405 b to attempt to determine a late decision 2408.

Finally, for improved accuracy and/or in the event the late decisionstage is unsuccessful (e.g., the late decision stage is unable to detector classify the additional compression data 2410 using the second stageCNN 2405 b), CNN 2400 may proceed to a final decision stage, as shown inFIG. 24C. In the final decision stage of FIG. 24C, for example, thecompressed visual data 2402 may be fully decompressed using adecompression engine 2412, and the decompressed visual data 2414 (e.g.,pixel domain data) may then be evaluated using a final stage CNN 2405 cto determine a final decision 2416.

Accordingly, the collective stages of multi-domain cascade CNN 2400 aredepicted in FIG. 24C, where an early stage is used to generate an earlydecision based on an initial subset of compressed domain data, and laterstages are used to generate re-fined or final decisions based onadditional compressed domain data and eventually pixel domain data.

The described embodiments of multi-domain cascade CNN 2400 providenumerous advantages. First, visual data (e.g., images or video) does notneed to be fully decompressed before its contents can be analyzed usingdeep learning neural networks, thus reducing memory usage andcomputation typically required for decoding or decompressing the visualdata. Next, the cascading approach of CNN 2400 avoids the need totransmit certain compressed data to the cloud, such as when an earlydecision can be reached by an edge or fog node, thus improving bandwidthusage. Finally, a large portion of the overall analysis often occurs inthe early decision stage, which typically involves a simplified CNN ormachine learning model, thus reducing the overall computationalcomplexity.

FIGS. 25A and 25B-31A and 31B illustrate the use of butterfly operationsto implement a multi-domain convolutional neural network (CNN) that iscapable of processing both raw and compressed visual data.

As discussed above, many visual analytics systems require visual data tobe fully decompressed before any visual processing can be performed(e.g., using deep learning neural networks), which is an approach thatsuffers from various inefficiencies, including higher processinglatency, additional transmission bandwidth, and so forth. Accordingly,this disclosure presents various embodiments of a deep learning neuralnetwork that is capable of analyzing compressed visual data directly. Inparticular, the described embodiments present a multi-domain CNN thatuses butterfly operations to enable visual data processing in either thepixel domain or the compressed domain.

To illustrate, existing deep learning CNNs (e.g., inception or ResNetCNN models) typically repeat an inner module multiple times, and theinner module aggregates the results from multiple convolution layersand/or the original input at the end (analogous to a bottleneck). Forexample, FIGS. 25A and 25B illustrate a traditional 27-layer inceptionmodel CNN 2500, and FIGS. 26 and 27 illustrate example inner modules2600 and 2700 for an inception model CNN. In particular, FIG. 26illustrates an inner module 2600 implemented without dimensionreduction, while FIG. 27 illustrates an inner module 2700 implementedwith dimension reduction. These CNN implementations are designed toprocess visual data in the pixel domain (e.g., raw or uncompressedvisual data).

FIGS. 28 and 29, however, illustrate example CNN inner modules 2800 and2900 that use butterfly operations to enable multi-domain visual dataprocessing in either the pixel domain or the compressed domain.Butterfly operations, for example, are operations that can be used totransform compressed domain data (e.g., DCT domain data) back to thepixel domain. Accordingly, by incorporating butterfly layers into a CNN,the CNN can be provided with compressed visual data as its originalinput, and as the compressed data is processed by the successive CNNlayers, the compressed data is at least partially transformed ordecompressed back to the pixel domain using the butterfly layers in theCNN.

FIG. 28 illustrates an inner CNN module 2800 implemented withoutdimension reduction, while FIG. 29 illustrates an inner CNN module 2900implemented with dimension reduction. Moreover, as shown in theseexamples, additional butterfly layers or filters are added in parallelto the regular convolution layers. In some embodiments, for example, 2×2and/or 4×4 butterfly operations can be added in parallel to the regularconvolution and pooling layers. For example, in some embodiments, thebutterfly operations could be implemented similar to the examplebutterfly operation illustrated in FIGS. 31A-B.

With respect to inner module 2800 of FIG. 28, for example, butterflylayers 2830 a,b are added in parallel to convolution layers 2810 a-c andpooling layer 2820, and the butterfly layers 2830 include verticalN-point butterfly operations 2830 a and horizontal N-point butterflyoperations 2830 b. For example, in some embodiments, the butterflyoperations may be performed for both the vertical pixels and thehorizontal pixels. Similarly, with respect to inner module 2900 of FIG.29, butterfly layers 2930 a,b are added in parallel to convolutionlayers 2910 a-e and pooling layers 2920 a-b, and the butterfly layers2930 include vertical N-point butterfly operations 2930 a and horizontalN-point butterfly operations 2930 b.

Note that this approach, however, does not require multiple butterflylayers to be stacked within a single inner module, as the CNN does nothave to perform a complete inverse DCT. For example, the goal ofmultiple convolution layers is to extract/transform the input data to afeature space where the fully connected layers can easily separatedifferent clusters. Accordingly, the butterfly layers do not have toperform a complete inverse DCT, and instead, they can simply be designedto aid in extracting and transforming the input data into the featurespace. In this manner, a complete or entire stack or organized butterflylayers does not need to be included in the CNN.

Moreover, the weights of each butterfly can be adjusted during thetraining phase, and thus the decision of whether to use the butterflylayers and/or how much to rely on them will be adjusted automatically.

FIG. 30 illustrates an alternative embodiment of a multi-domain CNN 3000with butterfly layers 3002 and normal layers 3004 arranged sequentiallyrather than in parallel.

FIGS. 31A and 31B illustrate an example of a one-dimensional (1D)N-point butterfly operation. In particular, the illustrated example is a4-point butterfly operation, meaning the butterfly operation isperformed using four data points 3110 a-d. In other embodiments,however, butterfly operations may be implemented using any number ofdata points. Moreover, in some embodiments, data points 3110 a-d mayrepresent compressed pixel data, such as DCT coefficients.

In some embodiments, the butterfly operation may be performed inmultiple stages. In each stage, for example, the butterfly operation maygenerate two outputs or channels using separate addition and subtractionoperations (e.g., by computing the sum of two points over a largedistance and the difference of two points over a large distance). Forexample, during a particular stage, the 1^(st) and 4^(th) points may beadded together to compute their sum (1^(st) point+4^(th) point), andalso subtracted to compute their difference (1^(st) point-4^(th) point).The points may then be shifted up cyclically and the process may berepeated for the next stage. For example, after each stage, the 4^(th)point becomes the 3^(rd) point, the 3^(rd) point becomes the 2^(nd)point, the 2^(nd) point becomes the 1^(st) point, and the 1^(st) pointbecomes the 4^(th) point. After the points are shifted, the next stageof the butterfly operation is performed by repeating the addition andsubtraction on the 1^(st) on 4^(th) points (e.g., using the new orderingof points).

In FIGS. 31A-B, for example, the addition and subtraction operations forthe first stage of a butterfly operation are shown. In particular, FIG.31A illustrates the addition operation, and FIG. 31B illustrates thesubtraction operation. In FIG. 31A, for example, the 1^(st) point (3110a) and the 4^(th) point (3110 d) are added together to compute a newpoint (3120 a) that represents their sum. Similarly, in FIG. 31B, the4^(th) point (3110 d) is subtracted from the 1^(st) point (3110 a) tocompute a new point (3130 d) that represents their difference. Thepoints are then shifted in the manner described above to perform thesubsequent stages of the butterfly operation.

Accordingly, the butterfly operations can be incorporated into a CNN inthis manner in order to enable processing of visual data in both thepixel domain and compressed domain (e.g., DCT domain), thus eliminatingthe requirement of fully decompressing visual data before analyzing itscontents using a deep learning neural network. For example, rather thanexplicitly performing an inverse DCT transform to fully decompressvisual data before processing it using a CNN, the CNN can instead beimplemented using butterfly layers to inherently incorporatedecompression functionality into the CNN, thus enabling the CNN to beprovided with compressed data as input.

FIGS. 32 and 33 illustrate an example embodiment of a three-dimensional(3D) CNN 3200 that is capable of processing compressed visual data. Insome embodiments, for example, 3D CNN 3200 could be used in theimplementation of, or in conjunction with, the compression-based CNNembodiments described throughout this disclosure (e.g., the CNNs ofFIGS. 24 and 28-31).

Many visual analytics systems require visual data to be decompressedbefore any processing can be performed, such as processing by a deeplearning neural network. To illustrate, FIG. 34 illustrates an exampleof a pixel-domain CNN 3400, and FIG. 35 illustrates an example of anassociated pixel-domain visual analytics pipeline 3500. In theillustrated example, pixel-domain CNN 3400 performs object detection andclassification for visual analytics using data in the pixel or imagedomain (e.g., using decompressed visual data). For example, theconvolutional kernels in the early layers of the CNN implementtwo-dimensional (2D) convolutions on the image data, and multiple layersof convolutions, pooling, and rectified linear unit (ReLU) operationsare repeated in order to successively extract combinations of featuresfrom the earlier layers. Moreover, because CNN 3400 operates onpixel-domain data, compressed visual data must be fully decompressedbefore it can be processed by CNN 3400. For example, as shown by visualanalytics pipeline 3500 of FIG. 35, the original pixel domain data 3502is first compressed by a video encoder 3510 (e.g., prior to transmissionover a network), and the compressed data 3504 is subsequentlydecompressed by a video decoder 3520 before performing video analytics3540 (e.g., using a CNN).

In the illustrated embodiment of FIGS. 32 and 33, however, 3D CNN 3200processes compressed visual data directly using a 3D format designed toimprove processing efficiency. For example, the input image may betransformed into the DCT domain and reshaped into a 3D format in orderto separate the DCT transform coefficients into different channels. Inthis manner, the reshaped DCT transform data is arranged in a mannerthat provides better correlation between the spatial and transformdomain coefficients. The reshaped DCT transform data can then beprocessed directly by a CNN (e.g., using 3D convolutions to performfeature extraction), which ultimately enables the CNN to be trainedfaster. For example, by eliminating the decompression step required byexisting approaches, processing efficiency is improved, particularly forcomputing environments that do not include built-in hardware videodecompression accelerators.

In some embodiments, for example, 3D CNN 3200 may be designed to operatedirectly on compressed visual data (e.g., video frames) represented inthe DCT domain using a 3D matrix. For example, in some embodiments, theDCT block indices may be represented by the x and y dimensions of the 3Dmatrix, while the DCT transform magnitude vectors may be organized alongthe z dimension. In this manner, the convolutional kernels in the firstlayer of the new CNN architecture can be implemented using 3D filtersdesigned to better capture the spatial and frequency domain correlationsand features of the compressed data, thus improving the performance ofthe CNN operation in the DCT domain.

The majority of common video and image encoding schemes use discretecosine transforms (DCT) to convert spatial pixel intensities tofrequency domain representations. The illustrated embodiment is based onthe observation that once image data is split into 4×4 pixel blocks andpassed through a transform such as DCT, the transformed data hasdifferent correlation properties than the original data. For example,with respect to a DCT transform, the DC coefficients of adjacent blocksare often strongly correlated, while the corresponding higher frequencyAC coefficients of adjacent blocks may be similarly correlated.

Accordingly, FIG. 32 illustrates an approach for transforming a 2D imageinto a 3D matrix of DCT data, which is arranged in a manner that allowsthe DCT data to be processed more efficiently by a CNN. In theillustrated example, an input image of size N×N (reference numeral 3210)is first broken up into 4×4 pixel blocks (example reference numeral3212), and each 4×4 pixel block is passed through a DCT transform. Theresulting DCT transform domain data (reference numeral 3220) is thenstored in a 3D matrix, where the x and y dimensions correspond to thespatial block indices and the z dimension contains vectors of DCTcoefficients (reference numeral 3222), which include 16 coefficients pervector. Accordingly, the resulting transform domain data (referencelabel 3220) has dimensions of size K×K×16, where K=N/4.

Next, as shown in FIG. 33, the transform domain data represented usingthe 3D matrix (reference label 3220) is input into the CNN (referencelabel 3200), which includes a first layer of 3D convolutional kernelsthat use 3D filters. This layer extracts both spatially correlatedfeatures in the x-y plane along with any specific signatures in thefrequency axis (z dimension), which can be used as input to succeedinglayers.

The illustrated embodiment provides numerous advantages, including theability to directly process compressed visual data in an efficientmanner, thus eliminating the need to decompress the data beforeanalyzing its contents (e.g., using a deep learning neural network). Inthis manner, the overall computational complexity of visual analyticscan be reduced. Moreover, because compressed or DCT domain data isquantized and thus represented using a more compact form than theoriginal visual data (e.g., video frame), the overall CNN complexity maybe further reduced compared to a conventional pixel-domain CNN. Forexample, with respect to visual data (e.g., images or video) compressedin certain compression formats such as JPEG or M-JPEG, the DCTcoefficients are quantized, and typically the highest frequencycomponents may be zeroed out by the quantization. Thus, the total volumeof non-zero data processed by the CNN is reduced compared to theoriginal image data. Accordingly, based on the data volume reduction ofthe compressed data (e.g., due to DCT coefficient quantization), the CNNcomplexity may be further reduced, and the training speed of convergencemay improve.

FIGS. 36 and 37 illustrate example embodiments of visual analyticspipelines 3600 and 3700 that perform visual analytics on compressedvisual data (e.g., using the compression-based CNN embodiments describedthroughout this disclosure). As shown by these FIGURES, the decoding ordecompression step in the visual analytics pipeline is optional and/ormay be omitted entirely. For example, as shown by visual analyticspipeline 3600 of FIG. 36, the original pixel domain data 3602 is firstcompressed by a video encoder 3610 (e.g., prior to transmission over anetwork), and the compressed data 3604 may optionally be partiallydecompressed by a video decoder 3620 before performing visual analytics3630 on the fully or partially compressed data 3606. Similarly, as shownby visual analytics pipeline 3700 of FIG. 37, the original pixel domaindata 3702 is first compressed by a video encoder 3710 (e.g., prior totransmission over a network), and visual analytics (e.g., imageclassification) 3720 is then directly performed on the compressed data3704.

FIG. 38 illustrates a performance graph 3800 showing the precision of aCNN trained using compressed visual data (e.g., 4×4 transform DCTinputs), such as the compression-based CNNs described throughout thisdisclosure.

FIG. 39 illustrates a flowchart 3900 for an example embodiment ofcontext-aware image compression. In some embodiments, flowchart 3900 maybe implemented using the embodiments and functionality describedthroughout this disclosure.

Today, many people rely on the cloud for storing or backing up theirphotos. Typically, photos are stored as individually compressed files orunits. In the current computing era, however, that approach is ofteninefficient. For example, people increasingly use their mobile devicesto take photos, and each new generation of mobile devices are updatedwith cameras that support more and more megapixels, which results inlarger volumes of photos that require more storage space. Moreover,people often capture multiple photos of the same object or scene duringa single occasion, which often results in a close temporal correlationamong those photos, along with substantial redundancy. Accordingly, dueto the redundancy across similar photos, individually compressing andstoring each photo can be an inefficient approach. For example,traditionally, each photo is compressed and saved independently using aparticular image compression format, such as JPEG. By compressing eachphoto individually, however, current approaches fail to leverage theinter-picture correlations between groups of similar photos, and thusmore storage space is required to store the photos. For example, twophotos that are nearly identical would still require double the storageof a single photo.

Accordingly, in the illustrated embodiment, groups of similar or relatedphotos are compressed and stored more efficiently. For example, contextinformation associated with photos is extracted and used to identifysimilar or related photos, and similar photos are then compressedjointly as a group. The contextual information, for example, could beused to identify a group of pictures from a single user that were takenvery close in time and/or at the same location. As another example, thecontextual information could be used to identify a group of picturestaken by different users but at the same location. Accordingly, theidentified group of similar photos may be compressed using video codingin order to leverage the inter-photo correlations and ultimatelycompress the photos more efficiently. In this manner, compressingrelated or correlated images using video compression rather thanstandard image compression can significantly reduce the storage spacerequired for the photos (e.g., 2-5 times less storage space in somecases). Accordingly, this approach can be used to save or reduce storagein the cloud.

The flowchart may begin at block 3902 by first obtaining a new photo. Insome cases, for example, the new photo could be captured by the cameraof a mobile device. In other cases, however, any type of device orcamera may be used to capture the photo.

The flowchart may then proceed to block 3904 to collect contextinformation associated with the new photo. For example, when a photo isnewly captured (e.g., by a mobile device), corresponding contextinformation associated with the photo is collected, such as a timestamp,GPS coordinates, device orientation and motion states, and so forth.

The flowchart may then proceed to block 3906 to determine if a matchingmaster photo can be identified for the new photo. In some embodiments,for example, the context information of the new photo is compared to thecontext information of other previously captured master photos todetermine whether the new photo is closely correlated to any of theexisting master photos. For example, if the photo is taken in the samelocation, within a certain amount of time, and with little phonemovement compared to a master photo, it is likely that the new photo ishighly correlated with the master photo. Further, in some embodiments,image feature matching techniques can then be applied to confirm thephoto correlation. In some embodiments, for example, a scale-invariantfeature transform (SIFT) may be used to determine whether a pair ofphotos are sufficiently correlated or matching.

If a matching master photo is identified at block 3906, the flowchartmay then proceed to block 3908 to encode the new photo with the matchingmaster photo. In some embodiments, for example, a video codec (e.g.,H.264) may be used to compress the new photo as an inter-frameassociated with the master photo. For example, video codecs typicallyprovide inter-frame encoding, which effectively utilizes the temporalcorrelation between similar images to improve the coding efficiency.

In some embodiments, a master photo may include any photo that iscompressed without reference to other parent or related images, while aslave photo may include any photo that is compressed with reference to amaster or parent image (e.g., using inter-frame mode of a video codec).Accordingly, a slave photo must efficiently record or correlate relevantinformation of its master photo, so that when the slave photo needs tobe decoded for display of the entire image, the associated master photocan be quickly identified.

If a matching master photo is NOT identified at block 3906, theflowchart may then proceed to block 3910 to encode the new photo byitself. For example, when the new photo does not match any of theexisting master photos, the new photo is encoded without referencing anyother photos, and the flowchart may then proceed to block 3912 todesignate the new photo as a master photo, allowing it to potentially becompressed with other subsequently captured photos.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 3902 to continue obtaining and compressing newly captured photos.

Privacy/Security

In distributed visual processing systems, it is important to implementeffective privacy and security policies to protect sensitive visual dataof underlying users or subjects (e.g., images or video with people'sfaces). Accordingly, in some embodiments, the visual fog architecturedescribed throughout this disclosure may be implemented using a varietyof privacy and security safeguards.

In some embodiments, for example, privacy-preserving distributed visualprocessing may be used in order to schedule or distribute visionworkloads across available fog nodes in an efficient manner, while alsoadhering to any applicable privacy and/or security constraints.

Similarly, a multi-tiered storage approach may be used to store visualdata in different locations and/or for different durations of time,depending on the particular level of sensitivity of the data. Forexample, the cloud may be used for long term storage of less sensitiveor high-level visual data or metadata, while edge devices (e.g., onpremise gateways) may be used for storage of highly sensitive visualdata.

Moreover, certain vision operations may be implemented usingprivacy-preserving approaches. For example, for some vision applications(e.g., automated demographics identification), feature extraction andrecognition may be implemented using cameras and sensors that capturetop-down views rather than intrusive frontal views.

As another example, gateway cloud authentication may be used to securelyauthenticate gateways and/or other fog devices to the cloud using JSONweb tokens.

As another example, wallets or distributed keys, along with MESH orGOSSIP based communication protocol, can be used to provide improved andmore secure key management solutions.

Stream multiplexing may be used in application layer routing forstreaming media, for example, by multiplexing visual sensors overmultiple channels and introducing entropy to make channel predictionmore difficult. For example, additional security can be provided byintroducing entropy and other noise (e.g., chaff signals) designed tocomplicate channel prediction, thus thwarting efforts of maliciousactors to pick up on video feeds.

As another example, a self-sovereign blockchain can be used to providemulti-tenant device identification. For example, the blockchain can beused to handle the orchestration and acceptance of device identitiesacross multiple visual fog networks (e.g., even for legacy systems),thus allowing devices to assert their identity without relying on thirdparty or centralized services. A self-sovereign blockchain can similarlybe used for other purposes, such as managing a collection of distributedcomputing algorithms.

As another example, blockchain lifecycle management (e.g., managing theinstantiation and lifecycle of blockchains) can be used to provide anadditional level of security on blockchains used in a visual fogarchitecture. For example, blockchain lifecycle management can be usedto ensure that a particular blockchain is implemented correctly andbehaves as expected.

As another example, stakeholder management can be used to provide a setof protocols and frameworks to allow self-interests to be asserted,while arbitrating against conflicts in an equitable way.

FIGS. 40A-C illustrate an example embodiment of a privacy-preservingdemographic identification system 4000. Identifying human demographicattributes (e.g., age, gender, race, and so forth) can be leveraged fora variety of use cases and applications. Example use cases includehuman-computer interaction, surveillance, business and consumeranalytics, and so forth. In retail and healthcare segments, for example,defining a target audience and developing customer profiles has become acritical factor for successful brand strategy development.

In some embodiments, for example, computer vision and/or facialrecognition technology may be used to identify human demographics. Forexample, demographics could be identified based on frontal and/or sidefacial features extracted using computer vision facial recognitiontechnology. The use of frontal facial recognition technology in public,however, may implicate potential privacy concerns. Moreover, demographicidentification is crucial across different domains and should not belimited to only frontal-based sensors and recognition techniques,particularly in the Internet-of-Things (IoT) era, which is projected tohave over 20 billion connected devices by year 2020. Further, whenlimited to frontal-based vision sensors, it may be challenging todevelop a demographics identification system that overcomes the personocclusion problem, while also providing wide processing viewing angles.

Accordingly, in the illustrated embodiment of FIGS. 40A-C,privacy-preserving demographic identification system 4000 uses one ormore top-view sensors 4015 to identify human demographics. In someembodiments, for example, either a single sensor 4015 or multiplesensors 4015 may be used to capture top-down views of humans, ratherthan conventional frontal views. Moreover, human demographics may thenbe identified based on features extracted from the top-down viewscaptured by the sensors 4015. In this manner, the use of top-viewsensors 4015 enables human demographics to be automatically identifiedwhile preserving privacy, providing wider sensor viewing angles, andreducing susceptibility to occlusion.

FIG. 40A illustrates a high-level implementation of demographicidentification system 4000. In the illustrated embodiment, edge devices4010 include multiple sets of top-view sensors 4015 a-c that are usedfor sensing humans. For example, each set of top-view sensors 4015 a-cmay include one or more sensors that are capable of capturinginformation about their surrounding environment. The informationcaptured by top-view sensors 4015 a-c is then processed in the fog 4020to detect humans and identify their demographics. The contextualinformation extracted by the fog 4020 (e.g., human demographics) maythen be transmitted to the cloud 4030 for further analytics, such aspeople profiling or generating heat maps.

FIG. 40B illustrates an example of a set of top-view sensor(s) 4015associated with demographic identification system 4000 of FIG. 40A. Asshown in the illustrated example, top-view sensors 4015 include acollection of one or more sensors positioned above an area that isaccessible to humans 4002. In some embodiments, for example, top-viewsensors 4015 could be mounted to the ceiling of a retail store near theentrance. Moreover, top-view sensors 4015 can include any type and/orcombination of sensor(s), such as a vision camera, infrared camera,light detection and ranging (LiDAR) sensor, and so forth. In thismanner, top-view sensors 4015 can be used to capture top-viewrepresentations of humans 4002 that pass below the sensors. Moreover, asdescribed further with respect to FIG. 40C, the top-view representationscaptured by top-view sensors 4015 can then be processed further toidentify the demographics of humans 4002 captured by the sensors.

FIG. 40C illustrates an example of the demographics identificationprocess performed by the fog 4020 in demographic identification system4000 of FIG. 40A. In the illustrated example, the demographicsidentification process involves (i) training a demographicsclassification model, and (ii) identifying demographic information usingthe trained demographics classification model with top-view sensor dataas input.

The process of training the demographics classification model isillustrated by blocks 4021-4024. At block 4021, a training database oftop-view human data must first be obtained or generated. In someembodiments, for example, the training database may include datacaptured by top-view sensors 4015, such as camera images, infraredimages, point clouds, and so forth. At block 4022, features that aretypically representative of human demographics are then selected/trainedfrom the database using feature extraction methodologies, such asprincipal component analysis (PCA), discrete cosine transforms (DCT),machine learning (e.g., deep learning using a neural network), and soforth. At block 4023, the selected/trained features are then provided asinput to a process used to train a demographics classification model. Atblock 4024, the trained demographics model is then saved in the fog 4020for subsequent use during the demographics identification process, asdescribed further below.

The process of identifying human demographics is illustrated by blocks4025-4029. At block 4025, sensor data is captured by edge devices 4010using one or more top-view sensor(s) 4015, such as a vision camera,infrared camera, LiDAR sensor, and so forth. The raw sensor data (e.g.,RGB images, thermal images, point clouds) is then transmitted from theedge 4010 to the fog 4020 in order to perform data pre-processing in thefog 4020 (e.g., on-premises), such as data transformations, de-noising,and so forth. At block 4026, person detection is then performed on thepre-processed input stream. In some embodiments, for example, thepre-processed input stream is analyzed to determine if a person iscaptured in the underlying visual data. As an example, pre-processedimage data from a top-view camera may be analyzed to determine if theimage contains a person, and if so, the portion of the image thatcontains the person may be extracted. At block 4027, features that aretypically representative of human demographics are then selected orextracted from the detected person using feature extraction/machinelearning techniques. At block 4028, the extracted features from block4027 and the pre-trained demographics model from block 4024 are thenused by a demographics classifier to classify the demographic attributesof the detected person. At block 4029, demographic informationassociated with the detected person is then identified based on theoutput of the demographics classifier.

The described embodiments of top-view demographics identificationprovide numerous advantages. As an example, the described embodimentsenable demographic information to be accurately identified based ontop-down views of humans captured using a single- or multi-sensorapproach. Compared to a frontal view approach, for example, a top-downor aerial perspective provides a wider angle of view for processing,reduces the problem of blocking or occlusion of people captured by thesensors, and preserves depth information associated with people andfeatures captured and processed by the system. In addition, thedescribed embodiments are less privacy-intrusive, as they only capturetop views of people rather than other more intrusive views, such asfrontal views. The described embodiments also identify demographicinformation based on permanent or lasting anthropometry features ratherthan features that may change or vary. Moreover, unlike motion-baseddetection approaches, the described embodiments are operable using onlystatic views or images and do not require continuous image sequences orvideos. Further, the described embodiments can be leveraged for avariety of use cases and applications, including retail, digitalsurveillance, smart buildings, and/or other any other applicationsinvolving human sensing, person identification, person re-identification(e.g., detecting/tracking/re-identifying people across multiplemonitored areas), and so forth.

FIG. 53 illustrates a flowchart 5300 for an example embodiment ofprivacy-preserving demographics identification. In some embodiments, forexample, flowchart 5300 may be implemented by demographicsidentification system 4000 of FIGS. 40A-C.

The flowchart may begin at block 5302 by obtaining sensor data from atop-view sensing device. A top-view sensing device, for example, may beused to capture sensor data associated with the environment below thetop-view sensing device (e.g., from a top-down perspective). In someembodiments, the top-view sensing device may include a plurality ofsensors, including a camera, infrared sensor, heat sensor, laser-basedsensor (e.g., LiDAR), and so forth.

The flowchart may then proceed to block 5304 to perform preprocessing onthe sensor data, such as data transformations, filtering, noisereduction, and so forth. In some embodiments, for example, the rawsensor data may be transmitted to and/or obtained by a processor that isused to perform the preprocessing. For example, the preprocessing may beperformed by an edge processing device at or near the network edge(e.g., near the top-view sensing device), such as an on-premise edgegateway.

The flowchart may then proceed to block 5306 to generate a visualrepresentation of the environment below the top-view sensing device. Thevisual representation, for example, may be generated using the sensordata captured by the top-view sensing device (e.g., camera images,infrared images, point clouds, and so forth). In some embodiments, forexample, the visual representation may be a three-dimensional (3D)representation or mapping of the environment from a top-downperspective. Moreover, in some embodiments, the visual representationmay be generated at or near the network edge (e.g., near the top-viewsensing device). For example, in some embodiments, an edge processingdevice (e.g., an on-premise edge gateway) may be used to generate thevisual representation.

The flowchart may then proceed to block 5308 to determine whether aperson is detected in visual representation. For example, if a personwas located under the top-view sensing device when the sensor data wascaptured, then the visual representation generated using the sensor datamay include a representation of the person from a top-view perspective.Accordingly, the visual representation may be analyzed (e.g., usingimage processing techniques) to determine whether it contains a person.In some embodiments, for example, the person detection may be performedat or near the network edge (e.g., near the top-view sensing device) byan edge processing device (e.g., an on-premise edge gateway).

If it is determined at block 5308 that a person is NOT detected in thevisual representation, the flowchart may proceed back to block 5302 tocontinue obtaining and processing sensor data until a person isdetected.

If it is determined at block 5308 that a person is detected in thevisual representation, however, the top-view representation of theperson may be extracted from the visual representation, and theflowchart may then proceed to block 5310 to identify one or morefeatures associated with the person. In some embodiments, for example,the top-view representation of the person may be analyzed to identify orextract anthropometric features associated with the person (e.g.,features or measurements associated with the size and proportions of theperson). For example, in some embodiments, the anthropometric featuresmay be identified by performing feature extraction using an imageprocessing technique, such as a discrete cosine transform (DCT),principal component analysis (PCA), machine learning technique, and soforth. Moreover, in some embodiments, the feature identification orextraction may be performed at or near the network edge (e.g., near thetop-view sensing device) by an edge processing device (e.g., anon-premise edge gateway).

The flowchart may then proceed to block 5312 to identify demographicinformation associated with the person (e.g., age, gender, race) basedon the identified features. In some embodiments, for example, a machinelearning model may be trained to recognize demographic information basedon human anthropometric features. In this manner, the machine learningmodel can be used to classify the identified features of the person torecognize the associated demographic information.

In some embodiments, the demographics identification may be performed ator near the network edge (e.g., near the top-view sensing device) by anedge processing device (e.g., an on-premise edge gateway). Moreover, insome embodiments, the edge processing device may transmit thedemographics information (e.g., using a communication interface) to acloud processing device to perform further analytics, such as generatinga heat map or a people profile.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 5302 to continue obtaining and processing sensor data from atop-view sensing device.

FIGS. 41-43 illustrate an example embodiment of privacy-preservingdistributed visual data processing.

In visual computing, multi-target multi-camera tracking (MTMCT) andtarget re-identification (ReID) are some of the most common workloadsacross different use cases. MTMCT involves tracking multiple objectsacross multiple views or cameras, while ReID involves re-identifying anobject (e.g., by extracting robust features) even after the objectundergoes significant changes in appearance. For example, in retail,MTMCT is often used to track shoppers within a store, while ReID may beused to extract and summarize robust features of shoppers so they canlater be re-identified (e.g., using MTMCT) in different circumstances,such as when a shopper has a significant change in appearance or visitsa different store.

Currently, there are no coherent end-to-end (E2E) solutions forperforming MTMCT and ReID that are scalable to large-scale visualcomputing systems (e.g., with tens of thousands of camera streams ormore). In particular, bandwidth limitations render it challenging todeploy such a system in a conventional cloud computing paradigm wherecameras send continuous video streams to the cloud for processing. Forexample, due to the large volume of video data generated by suchsystems, it is not feasible to funnel all of that data to the cloud forprocessing. On the other hand, it is unlikely that edge devices near thesource of the video data are capable of processing a complete visualprocessing workload in real time.

Moreover, privacy is also a challenge in scaling out such a system, assending visual data to the cloud for processing may implicate privacyconcerns. For example, in order to preserve customer privacy, manyretailers will not allow any video or images to be transmitted out oftheir stores.

Accordingly, FIGS. 41-43 illustrate an embodiment that solves theproblem of scaling out visual computing systems with MTMCT and ReIDcapabilities in a privacy-preserving manner. The illustrated embodimentpresents an edge-to-edge (E2E) architecture for performing MTMCT andReID across edge devices, gateways, and the cloud. The architecture isscalable and privacy-preserving, and can be easily generalized to manyvertical applications or use cases, such as shopper insights in retail,people searching in digital security and surveillance, player trackingand replays in sports, and so forth.

In some embodiments, for example, vision workloads may be scheduled andexecuted across visual fog nodes based on specified privacy constraints.As an example, privacy constraints for an MTMCT and/or ReID workload mayrequire tasks that output pictures with faces to remain on-premises(e.g., neither the tasks nor their output are assigned or transmittedbeyond the premise or to the cloud), be anonymized (e.g., face-blurred),and/or be deployed only on devices with enhanced link security.

In some embodiments, for example, rather than funneling every bit ofvisual data to the cloud for processing, intelligent decisions can bemade regarding how visual data and workloads are processed anddistributed across a visual computing system. Based on the privacyrequirements of a particular visual application, for example, a privacyboundary can be defined within the end-to-end paradigm of a visualcomputing system in order to achieve performance efficiency while alsopreserving privacy.

In some embodiments, for example, job partitioning can be used topartition a visual analytics workload into a directed acrylic graph(DAG) with vertices that represent primitive visual operations and edgesthat represent their dependencies. In this manner, the graph can be usedto represent the various tasks and associated dependencies for aparticular workload. Moreover, a privacy policy can be definedseparately for each dependency. Similarly, a device connectivity graphcan be used to represent the various devices and their connectivity inthe edge-to-cloud paradigm, and a privacy level agreement (PLA) can beestablished for each edge of connectivity in the graph. In this manner,the edge-to-cloud architecture can be implemented to include a coherentmanagement interface that performs end-to-end workload distributionwithout compromising privacy. For example, using the job partitioningapproach described above, workload distribution effectively becomes amapping problem of assigning the tasks of a workload onto devices in theedge-to-cloud paradigm. In some embodiments, for example, a globalscheduler can be used to determine an optimal mapping between tasks anddevices in order to maximize performance while preserving privacyconstraints.

FIG. 41 illustrates an example visual workload graph 4100 for performingMTMCT and ReID. Example workload 4100 includes a plurality of tasks,including preprocessing 4102, detection 4104, tracking 4106, matching4108, and database access 4110. Further, the dependencies between thesevarious tasks are represented by the solid and dotted lines in theillustrated example. Moreover, the solid lines represent unrestrictedaccess or transmission of the original visual data, while the dottedlines represent restricted or privacy-preserving access or transmission(e.g., transmitting only visual metadata, such as feature vectors). Inthis manner, a privacy policy can be defined for the workload, forexample, by specifying whether each task has unrestricted access orrestricted access to the original visual data.

FIG. 42 illustrates an example of an edge-to-cloud device connectivitygraph 4200. In the illustrated example, graph 4200 illustrates theconnectivity between various devices of a 3-tier edge-to-cloud network,which includes cameras 4210 a-c, gateways 4220 a-b, and the cloud 4230.In particular, the device connectivity is illustrated for bothedge-to-cloud communications (e.g., camera to gateway to cloud) as wellas peer-to-peer communications (e.g., gateway-to-gateway). Moreover, theconnectivity between the respective devices is represented using solidand dotted lines. For example, the solid lines represent high-securityconnectivity links, while the dotted lines represent limited-securityconnectivity links. In this manner, a privacy policy or privacy levelagreement (PLA) can be defined for an edge-to-cloud paradigm, forexample, by specifying the requisite security for each edge ofconnectivity in the graph.

FIG. 43 illustrates a privacy-preserving workload deployment 4300. Inparticular, workload deployment 4300 illustrates an example deploymentof the workload 4100 of FIG. 41 on edge-to-cloud network 4200 of FIG.42.

In the illustrated example, privacy is treated as an explicit constraintwhen performing task-to-device mapping to deploy the workload. In someembodiments, for example, workloads can be represented in linear formsto enable the mapping problem to be solved efficiently using state ofthe art integer linear programming (ILP) solvers.

In some embodiments, for example, when scheduling a particular workloadon an edge-to-cloud network, the workload and the edge-to-cloud networkmay each be represented using a graph, such as a directed acrylic graph(DAG). For example, the workload and its underlying tasks may berepresented by a workload or task dependency graph G_(T)=(V_(T), E_(T)),where each vertex v∈V_(T) represents a task, and each edge (u, v)∈E_(T)represents a dependency between task u and task v. Similarly, theedge-to-cloud network may be represented by a network or deviceconnectivity graph G_(D)=(V_(D), E_(D)), where each vertex v∈V_(D)represents a device in the network, and each edge (u, v)∈E_(D)represents the connectivity from device u to device v.

Moreover, the privacy policy (PP) for each task dependency in theworkload graph may be defined using a PP function p: E_(T)→

, such that the smaller the number (

), the more vulnerable the data transmission. Similarly, the privacylevel agreement (PLA) for each connectivity link in the deviceconnectivity graph may be defined using a PLA function s: E_(D)→

, such that the smaller the number (

), the more secure the link.

In this manner, based on the privacy policy (PP) and privacy levelagreement (PLA) functions, a privacy constraint (PC) can be defined ass(d)≤p(e), ∀e∈E_(T), d∈f(e), where f: E_(T)→x_(i=0) ^(k)E_(D) is themapping function from a particular workload to the edge-to-cloudparadigm. Essentially, f maps an edge in a workload graph to a path inan edge-to-cloud connectivity graph. For example, in the context ofvisual fog computing, f is a scheduling function that determines theparticular fog devices that the tasks of a workload should be assignedto, along with the particular network connectivity links between pairsof fog devices that should be used for the data transmissions.Accordingly, the above privacy constraint (PC) requires the privacylevel agreement (PLA) of a particular connectivity link to be capable ofaccommodating the privacy policy (PP) of a particular data transmissionsent over that connectivity link. For example, in some embodiments, adata transmission of PP level 1 (unrestricted access) can only map to alink of PLA level 1 (high security), while a data transmission of PPlevel 2 (privacy-preserving) can map to connectivity links of PLA level1 (high security) and PLA level 2 (limited security).

Moreover, in some embodiments, a visual fog schedule that adheres to theabove privacy constraint (PC) can be determined using integer linearprogramming (ILP). Integer linear programming (ILP) is a mathematicaloptimization or feasibility technique for solving or optimizing amathematical model represented by linear relationships. In particular,ILP can be used to optimize a linear objective function, subject toadditional linear equality and linear inequality constraints. In somecases, for example, an ILP problem can be expressed as follows:

$\begin{matrix}{{{minimize}\text{:}}\;} & {{c^{T}x}\mspace{76mu}} & {( {{objective}\mspace{14mu}{term}} )\mspace{65mu}} \\{{subject}\mspace{14mu}{to}\text{:}} & {{{Ax} \leq b}\mspace{45mu}} & ( {{inequality}\mspace{14mu}{constraint}} ) \\\; & {{{Cx} = d}\mspace{205mu}} & {( {{equality}\mspace{14mu}{constraint}} )\mspace{20mu}} \\{{{and}\text{:}}\mspace{65mu}} & {x \in \{ {0,1} \}^{K}} & {{( {{binary}\mspace{14mu}{constraint}} ).}\mspace{31mu}}\end{matrix}$

Moreover, this ILP model can be used to determine an optimal schedule fthat satisfies a specified objective (e.g., total network utilization),while also adhering to other additional constraints, such as a privacyconstraint and any other device, network, or mapping constraints. Forexample, when using the example ILP model above to perform visual fogscheduling, x presents the collection of possible schedules f, K is thelength of x, the objective term presents a scheduling objective to beminimized (e.g., total network utilization), and the inequality/equalityconstraints present any additional constraints, such as device, network,mapping, and/or privacy constraints. The above privacy constraint (PC),for example, can be presented as an inequality constraint of the ILPproblem.

FIG. 54 illustrates a flowchart 5400 for an example embodiment ofprivacy-preserving distributed visual processing. In some embodiments,for example, flowchart 5400 may be implemented using the visualcomputing embodiments described throughout this disclosure (e.g., theprivacy-preserving distributed visual processing techniques of FIGS.41-43 and/or the visual computing architecture described throughout thisdisclosure).

The flowchart may begin at block 5402 by identifying a new workload. Insome embodiments, for example, the new workload may include a pluralityof tasks associated with processing sensor data captured by one or moresensors. For example, in some embodiments, the sensor data may be visualdata captured by one or more vision-based sensors (e.g., a camera,infrared sensor, and/or laser-based sensor).

The flowchart may then proceed to block 5404 to generate a workloadgraph based on the workload. In some embodiments, for example, theworkload graph may include information associated with the underlyingtasks of the workload, along with the task dependencies among thosetasks.

The flowchart may then proceed to block 5406 to generate or identify adevice connectivity graph. In some embodiments, for example, the deviceconnectivity graph may include device connectivity informationassociated with a plurality of processing devices, such as edge, cloud,and/or intermediary network processing devices. The device connectivityinformation, for example, may include information associated with thedevice connectivity links among the plurality of processing devices.

The flowchart may then proceed to block 5408 to identify a privacypolicy associated with the workload and/or its underlying tasks. In someembodiments, for example, the privacy policy may comprise privacyrequirements associated with the task dependencies among the workloadtasks.

The flowchart may then proceed to block 5410 to identify privacy levelinformation associated with the plurality of processing devices. In someembodiments, for example, the privacy level information may includeprivacy levels provided by the device connectivity links among theplurality of processing devices. Moreover, in some embodiments, theprivacy level information may be specified by a privacy level agreement.

The flowchart may then proceed to block 5412 to identify a privacyconstraint for workload scheduling based on the privacy policy and theprivacy level information. In some embodiments, for example, the privacyconstraint may require the privacy level of a particular connectivitylink to be capable of accommodating the privacy policy of any taskdependency mapped to that connectivity link for data transmission.

The flowchart may then proceed to block 5414 to determine a workloadschedule. The workload schedule, for example, may include a mapping ofthe workload onto the plurality of processing devices. Moreover, in someembodiments, the workload schedule may be determined based on theprivacy constraint, the workload graph, and the device connectivitygraph. For example, in some embodiments, the workload schedule may bedetermined by solving an integer linear programming model based on theprivacy constraint, the workload graph, and the device connectivitygraph (e.g., as described in connection with FIGS. 41-43). In thismanner, a resulting workload schedule is determined in a manner thatadheres to the privacy constraint. Moreover, in some embodiments, amachine learning model may be used to optimize privacy-constrainedworkload scheduling.

In some embodiments, the resulting workload schedule may then bedistributed to the plurality of processing devices (e.g., via acommunication interface) in order to execute the workload.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 5402 to continue scheduling new workloads.

FIGS. 44-46 illustrate example embodiments of self-sovereign deviceidentification for distributed computing networks. In some embodiments,for example, a fog node (e.g., IoT sensor, actuator, camera, controller,gateway, and/or any other type of fog node) may be a “multi-tenant” nodethat is capable of participating in multiple different distributedcomputing networks (e.g., visual fog networks). Moreover, certainnetworks may require a new fog node to be “on-boarded” or “commissioned”before the fog node is allowed to access each network (e.g., using theonboarding/commissioning protocols of the Open Connectivity Foundation(OCF) and/or Intel's Secure Device Onboard (SDO) technology). Manyvisual computing solutions, however, may assume that ownership of a nodeis singular, meaning each node has only one owner. Accordingly,ownership disputes may arise from a multi-tenant fog node'sparticipation in multiple fog networks. The true or original owner of amulti-tenant fog node, however, has an interest in avoiding theseownership disputes. Accordingly, many visual computing solutions areunsuitable for multi-tenant fog nodes, which may participate in multiplefog networks while also abiding by each network's onboarding orcommissioning protocols (e.g., as defined by OCF or Intel SDO).

Accordingly, in the illustrated embodiments, a multi-tenant fog node canuse a self-sovereign device identity in order to allow the node owner toretain an assertion of ownership even when the fog node participates in,or roams to, other fog networks. In some embodiments, for example, aself-sovereign identity blockchain may be used to register theidentities of fog nodes or devices. A blockchain, for example, may be adynamic list of records or blocks that are linked and/or secured usingcryptographic approaches. In some embodiments, for example, each blockin a blockchain may include a hash pointer linking to a previous block,a timestamp, transaction data, and so forth. Accordingly, in someembodiments, a blockchain can be used as a distributed ledger forrecording transactions in an efficient, verifiable, and/or permanentmanner. In visual computing, for example, before adding a deviceidentifier for a new fog node, a blockchain may optionally be used toverify that the identifier has not been previously asserted by anothernode. Further, the public key used to verify the device identity of thefog node may also be contributed to the blockchain, allowing the deviceto later prove it is the rightful owner of its identity.

FIG. 44 illustrates an example embodiment of a distributed computingarchitecture 4400 with multi-tenant device identification. In theillustrated embodiment, architecture 4400 includes fog networks A and B4410 a-b, self-sovereign identity blockchain 4420, and new fog device4430, as described further below.

A new fog device 4430 that is seeking to be used in multiple fognetworks 4410, but is not exclusive to any particular fog network, maynot have sufficient resources or capabilities to create and maintainvirtual sandbox environments for each of the fog networks. Moreover,each fog network 4410 may have a large set of its own local fog devicesthat are exclusive to that network and do not roam into other fognetworks. Accordingly, reusing device identifiers may not pose asignificant problem of duplicative identifiers until a new device 4430with a conflicting identity roams into a particular fog network.

There is often a cost associated with changing the identity of a device,however, as credentials, access tokens, and application logic may belinked to the device identity. Moreover, the respective owners ofdevices with conflicting identifies have a self-interest in resolvingthe conflict (e.g., to avoid ownership disputes), but without bearingthe cost. For example, the conflicting devices may respectively vieweach other as “foreign,” and thus each device may want the other“foreign” device to bear the cost of an identity change. Accordingly, toresolve the opposing self-interests of devices with conflictingidentities, a blockchain 4420 may be used to provide a fair algorithmfor giving preference to a device for its use of an identity. In someembodiments, for example, the device that first registered a particularidentity with the blockchain 4420 is given preference in the event of aconflict.

FIG. 45 illustrates an example call flow 4500 for performing nameregistration of a self-sovereign device identity. In some embodiments,for example, registration of a self-sovereign device identity may beperformed before onboarding a new fog device onto a visual fog network.For example, prior to being on-boarded onto a visual fog network, a fogdevice may register its choice of device identity with a blockchain.

Moreover, the blockchain may have a policy for preventing duplicativeidentity registrations, for example, by first checking for duplicatesand only allowing registration if no duplicates exist. For example,duplicative identity detection may be performed by blockchain processingnodes as a requirement for vetting transaction blocks used for identityregistration. In the illustrated call flow 4500, for example, each nodeperforms the following steps:

(1) receive transaction request from new device: TX_(n+1)={S1, “A71C3”},where S1=Sign_K_(alice)(“A71C3”);

(2) compute hash H1=SHA256(“A71C3”);

(3) search hash tree of transaction attributes, whereB_(x-poss)=Search(TxTree, H1);

(4) IF B_(x-poss)=“H1” THEN return ERROR_DUP_FOUND;

(5) ELSE IF B_(x-poss)=“ ” THEN add TX_(n+1) to the current block whereCurrentBlock=[TX_(n+1), TX_(n), TX_(n−1), . . . , TX_(n−m)];

(6) compute new current block hash BH=SHA256([TX_(n+1), TX_(n),TX_(n−1), . . . , TX_(n−m)]);

(7) write BH to the blockchain at B_(curr-pos) (current position); and

(8) insert the tuple (H1, BH, B_(x-poss)) into TxTree.

In some embodiments, however, a less restrictive policy may be used,such as a policy that does not check for duplicates during identity orname registration, and instead relies on dispute resolution to resolveduplicative identities. For example, at the time a device is on-boardedonto a new fog network, the blockchain can be consulted to determine ifthe identifier has previously been used, and if so, conflict resolutioncan be performed. The advantages of a less restrictive policy includeimproved performance and the ability to support mass registrationworkloads, among other examples.

FIG. 46 illustrates an example call flow 4600 for conflict resolution ofself-sovereign device identities. In some circumstances, for example, itmay be unnecessary to verify that a new device identifier is globallyunique at the time of registration, and instead, conflicting identitiesmay be addressed when a new device is on-boarded onto a local fognetwork and an existing device already has the same identity.Accordingly, in some embodiments, conflicting device identities on aparticular fog network may be resolved using conflict resolution callflow 4600. In the illustrated call flow 4600, for example, a blockchainis used to resolve conflicts based on identity registration priority(e.g., the first device that registered a duplicative identity with theblockchain receives preference). Accordingly, this approach does notrequire device identifiers to be globally unique, but in the eventmultiple devices on the same fog network have the same identity, itrequires one of the devices to select a different identifier wheninteracting with that particular network. Moreover, the dispute overwhich device should pay the cost of changing its identity is resolvedusing the blockchain. By way of comparison, FIG. 47 illustrates anexample of device onboarding or commissioning in a visual fog networkwithout employing conflict resolution.

In this manner, based on the illustrated embodiments of FIGS. 44-46,device identity assertion can be performed at any time duringmanufacturing of a device, such as a system-on-a-chip (SoC) or any othertype of computing chip, circuit, or device. Moreover, rather than anassertion of device “ownership,” device identity assertion involves anassertion of identity ownership, where the device is the owner of theidentity. Accordingly, any appropriate entity within the supply chain ofa particular device (e.g., an original design manufacturer (ODM),original equipment manufacturer (OEM), distributor, retailer,value-added reseller (VAR), installer, or end customer) may assert theidentity of a device based on the sophistication and capability of theparticular entity.

FIGS. 48 and 49 illustrate example embodiments of algorithmidentification for distributed computing using a self-sovereignblockchain.

Distributed computing interoperability depends on agreement amongparticipating nodes regarding the particular algorithms used to processinformation at each node. In some cases, for example, algorithmagreement among nodes may depend on a central authority that manages aregistry or database of algorithm identifiers. In this manner,distributed nodes must rely on the registry for selection of theappropriate algorithms, otherwise interoperability is not achieved.

This dependence on central authorities can lead to service disruptions,however, such as when a registry goes offline, a registry is slow topublish new algorithm identifiers (e.g., thus slowing the pace at whichnew algorithms can be deployed), a central authority becomes the targetof politicizations (e.g., registration requests are held in ransom forprocessing fees, political favors, and/or other forms of manipulationthat are not tied to the economics of the distributed computingapplication), and so forth. For example, these approaches are oftenhighly centralized and may involve international or governmentalinstitutions, which may be prone to politicizations and/or governmentregulation (e.g., net neutrality). Moreover, since agreement on whichalgorithms to use is fundamental to distributed computing, a centralizedapproach for managing algorithm identifiers can create an artificialbottleneck or choking point, and entities seeking to impose regulationor control can effectively leverage the centralized design to restrictor prevent interoperability among distributed computing nodes.

Accordingly, in the illustrated embodiments of FIGS. 48 and 49, ablockchain is used to register a collection of distributed computingalgorithms (e.g., using self-sovereign algorithm identifiers). In someembodiments, for example, the blockchain may process an algorithmregistration request as a blockchain transaction, where the registrantselects a unique algorithm identifier and specifies the algorithmfunction. In various embodiments, the algorithm function may bespecified in human-readable form (e.g., as a natural languageexplanation or pseudocode), machine-readable form, and/ormachine-executable form. Moreover, as a condition or prerequisite toaccepting the algorithm registration, the particular algorithm may besubjected to various levels of “certification” by blockchain processingnodes. In this manner, an algorithm may be accepted with progressivelevels of assurance without altering the registered algorithmidentifier.

Accordingly, the described embodiments allow anyone that discovers auseful distributed computing algorithm to make that algorithm known andavailable to a large community. Blockchain networks, for example, arepresumed to be large in number and open to large communities of users.In this manner, members of the community can build distributed computingsystems without being hindered by bureaucratic roadblocks and oversight.As a result, the time between algorithm development and practicaldeployment can be minimized.

FIG. 48 illustrates an example embodiment of a distributed computingarchitecture 4800 with self-sovereign algorithm identification. In theillustrated embodiment, architecture 4800 includes fog networks A and B4810 a-b, along with a self-sovereign blockchain 4820 for registeringand identifying distributed computing algorithms 4430. In someembodiments, for example, architecture 4800 could be used to registerand/or identify algorithms used for visual fog computing.

As an example, if a useful distributed computing algorithm 4430 isinvented, discovered, and/or improved upon in a first fog network (e.g.,fog network A 4810 a), the first fog network may register the newalgorithm in a self-sovereign blockchain 4420 used for algorithmidentification. The blockchain processing nodes of the blockchain 4420may then progressively vet the algorithm in order to provideprogressively stronger assurances regarding its legitimacy (e.g., basedon the computational properties and outcome of the algorithm). Moreover,a second fog network (e.g., fog network B 4810 b) may subsequently benotified of the availability of the new algorithm, and may determinewhether the new algorithm has been adequately vetted (e.g., byconsulting the vetting status of the algorithm in the blockchain 4420).If the second fog network is satisfied with the vetting of the newalgorithm, the second fog network may agree to use the algorithm. Forexample, in some embodiments, after the algorithm has been adequatelyvetted, the first fog network and second fog network may agree to beginusing the new algorithm.

In some embodiments, the algorithm registration and vetting process mayinvolve: (1) registration of a self-sovereign algorithm identifier(SSAI); (2) peer-review of a human-readable description of thealgorithm; (3) machine analysis of a machine-readable representation ofthe algorithm (e.g., analysis by a logic processor to identify safebehavioral properties); and (4) execution of a machine-executableimplementation of the algorithm (e.g., execution in a sandboxenvironment used to analyze expected behavior). Moreover, once a certainthreshold (e.g., a majority) of blockchain processing nodes orevaluators achieve similar vetting results, the algorithm identity andits vetting criteria/results are recorded in a block of the blockchain4420.

FIG. 49 illustrates an example call flow 4900 for registering adistributed computing algorithm using a self-sovereign blockchain. Insome embodiments, for example, an algorithm may be registered using aself-sovereign blockchain to facilitate use of the algorithm across oneor more distributed or fog computing environments. Moreover, in someembodiments, the blockchain may leverage various levels of vetting toensure the algorithm behaves as expected, and verify that the algorithmidentifier is not already in use.

In the illustrated call flow 4900, for example, each blockchainprocessing node performs the following steps:

(1) receive transaction request from new device: TX_(n+1)={S1, “91E21”},where S1=Sign_K_(alice)(“91E21”, “Human-readable-description”,“Machine-readable-description”, “Machine-executable-implementation”);

(2) optional algorithm vetting (e.g., peer-review of a human-readablealgorithm description, logical analysis of a machine-readable algorithmdescription/representation, sandbox execution of a machine-executablealgorithm form);

(3) compute hash H1=SHA256(“91E21”);

(4) search hash tree of transaction attributes, whereB_(x-poss)=Search(TxTree, H1);

(5) IF B_(x-poss)=“H1” THEN return ERROR_DUP_FOUND;

(6) ELSE IF B_(x-poss)=“ ” THEN add TX_(n+1) to the current block, whereCurrentBlock=[TX_(n+1), TX_(n), TX_(n−1), . . . , TX_(n−m)];

(7) compute new current block hash BH=SHA256([TX_(n+1), TX_(n),TX_(n−1), TX_(n−m)]);

(8) write BH to the blockchain at B_(curr-pos)(current position); and

(9) insert the tuple (H1, BH, B_(x-poss)) into TxTree.

Once the vetting process completes, the blockchain contains a vetted andregistered instance of the algorithm and its associated identifier. Inthis manner, distributed computing nodes may then begin using thealgorithm (e.g., based on the algorithm identifier and optionally itsmachine-readable and/or machine-executable forms).

Applications

The visual fog architecture and embodiments described throughout thisdisclosure can be used for a variety of large-scale visual computingapplications and use cases, such as digital security and surveillance,business automation and analytics (e.g., retail and enterprise),transportation (e.g., traffic monitoring, navigation, parking,infrastructure planning, security or amber alerts), education, videobroadcasting and playback, artificial intelligence, and so forth.

As an example, the described embodiments could be used to implementwearable cameras for first responders that are capable of automaticallydetecting events or emergency situations and performing certainresponsive measures, such as notifying the appropriate personnel,triggering recording of the event by related or nearby cameras, and soforth.

As another example, the described embodiments could be used to implementa digital surveillance and security (DSS) system with people search orfacial recognition capabilities across visual data streams from multipledifferent cameras, sensors, and/or locations.

As another example, the described embodiments could be used to implementa digital surveillance and security (DSS) system with license plateidentification and fraud detection capabilities (e.g., identifying a carwith a license plate that does not match the corresponding vehiclerecord, identifying multiple cars with same license plate, and soforth).

As another example, the described embodiments could be used to providecustomer insights and analytics (e.g., for retail shoppers), such as anintra-store shopper trip summary (e.g., a list of products ordepartments interacted with by a shopper), an inter-store shopper tripsummary (e.g., identifying repeat customers by differentiating betweennew and returning customers as they enter a store with a single ormultiple locations), and so forth.

Similarly, the described embodiments could be used to providevisualization of customer or shopper insights and analytics (e.g.,visualizing a graph representation of visual metadata for humanconsumption).

As another example, the described embodiments could be used to performautomated demographics identification in a privacy-preserving manner(e.g., using top-view cameras or sensors for demographic mapping ofgender, age, race, and so forth).

As another example, the described embodiments could be used to performheat mapping in retail stores or other brick-and-mortar environments togenerate a representation of the crowd (e.g., using top-view sensors orcameras and/or multi-modal crowd emotion heat mapping). In someembodiments, for example, heat mapping could be leveraged foroptimization of store layouts, among other examples.

As another example, the described embodiments could be used to implementmulti-modal real-time customer reviews. For example, customer reviewsand/or customer satisfaction information could be collected and analyzedin real-time using multi-sensory data, which can be translated intoquantitative customer-to-customer reviews for any products or in-storeactivities of a particular store or brick-and-mortar environment.

Similarly, the described embodiments could be used to implementmulti-modal retailer-shopper double review, which may focus oncollection and analysis of both product reviews from customers andcustomer reviews from retailers.

As another example, the described embodiments could be used forautomated customer satisfaction analysis. For example, visual data couldbe used to measure customer satisfaction at check-out based onnon-verbal communication or body language. In this manner, customersatisfaction can be automatically inferred without requiring manualcustomer feedback (e.g., via a button or survey).

As another example, the described embodiments could be used to monitorthe effectiveness of employee-customer interactions. For example, visualdata could be used to measure and track the effectiveness ofcommunication between customers and salespeople with respect to findingdesired products or items. In some embodiments, for example, visual datacould be used to track users within a store, identify customer-employeecontact and interactions, and monitor the employee and/or customerresponses.

As another example, the described embodiments could be used to providedynamic ambience environments by identifying contextual information(e.g., relationships or actions) within a group of people. For example,visual data could be used to identify individuals and their associatedcontextual information to determine whether they are part of the samegroup (e.g., based on physical proximity and/or corresponding movement),and if so, to identify various parameters or characteristics of thegroup (e.g., a family shopping together in a store).

As another example, the described embodiments could be used to implementdouble auction real-time bidding (RTB). In some embodiments, forexample, visual data could be used to implement multi-shopper,multi-bidder real-time bidding (RTB) for brick-and-mortar retailers.

As another example, the described embodiments could be used to monitorand detect changes to store layouts based on visual data and/or sensors.

As another example, the described embodiments could be used for roboticinventory tracking and logistics (e.g., using stationary and/or movingcameras to track inventory of retail stores, warehouses, offices, and soforth).

As another example, the described embodiments could be used for roboticequipment inspection (e.g., using computer vision technology to inspectthe safety and/or health of equipment in a factory, plant, warehouse,store, office, and so forth).

As another example, the described embodiments could be used to provideautomated tipping recommendations, for example, based on multi-sensoryinputs and/or visual data reflective of factors that typically impactcustomer tipping behavior.

As another example, the described embodiments could be used forworkplace automation, such as workplace quality control, employeemonitoring, and so forth. In some embodiments, for example, visual datacould be used to analyze employee emotions in order to improveproductivity.

As another example, the described embodiments could be used foreducation and/or automated learning (e.g., using visual data to analyzestudent behavior in the classroom or at home in order to provide furtherassistance when appropriate).

As another example, the described embodiments could be used for videoplayback, such as user-centric video rendering, focused replays, and soforth. For example, user-centric video rendering could be used toperform focused rendering on 360-degree video by analyzing what the useris focusing on, and performing no or low-resolution processing onportions of the video that are outside the focus area of the user (e.g.,for virtual-reality (VR) and/or augmented-reality (AR) applications). Asanother example, focused video replays could be used to automaticallyfocus the rendering of a video replay on an area of interest, such asthe portion of a sports replay where most players are located.

As another example, the described embodiments could be used to trainartificial intelligence systems. In some embodiments, for example,visual data could be used to automatically generate ground truthinformation that can be used to train artificial intelligence or machinelearning models, such as deep learning neural networks.

As another example, the described embodiments could be used to implementa ubiquitous visual computing witness, as described further below inconnection with FIGS. 55-61.

These examples are merely illustrative of the limitless universe ofvisual applications and use cases that can be implemented using thevisual fog architecture described throughout this disclosure.

Ubiquitous Visual Computing Witness

FIGS. 55-56 illustrate an example embodiment of a ubiquitous visualcomputing witness. A ubiquitous witness addresses the problem ofcollecting evidence for events, incidents, or anomalies of interest in atimely, accurate, and comprehensive manner. For example, the policedepartment is a government agency devoted to law enforcement and publicsafety, which often requires them to conduct investigations intocriminal activity, automobile accidents (e.g., to identify the cause),and so forth. Similarly, a neighborhood watch is an organized group ofpeople devoted to monitoring and preventing crime and vandalism within aneighborhood. These types of functions often require evidence to becollected from various sources, including eye witnesses, physicalenvironments, electronic sources (e.g., surveillance systems), and soforth. The major issues in the aforementioned use cases lie in the factthat often times the most important evidence is sourced from 3^(rd)parties. In a neighborhood watch, for example, a neighbor's camera maycapture a much clearer view of an incident in or around a nearby house.In automobile incident investigations, evidence may need to be collectedand combined from multiple sources, such as nearby cars, roadsideinfrastructure or roadside units (RSUs) (e.g., lamp posts, signage,traffic lights), and so forth. Thus, comprehensive data aggregation andtimeliness are both crucial to the fact-gathering process.

Existing approaches for evidence gathering suffer from variousdrawbacks. For example, there are no automated solutions for evidencegathering. Moreover, for electronic devices that continuously generateand/or stream data (e.g., sensors, cameras), the data retention policiescan be rather short due to resource constraints. For example, data mayonly be retained for a couple of hours for vehicledashboard/surveillance cameras due to limited storage capacity on an SDcard. Further, manual approaches to evidence gathering often facevarious challenges. In particular, ownership of the data can presentproblems, especially in the absence of a shared authority that brokersaccess to the data.

Accordingly, this disclosure describes various embodiments of aubiquitous visual computing witness. In particular, this disclosureproposes a novel new application of a ubiquitous witness implementedusing an infrastructure of visual fog computing and visual fognetworking for various example use cases. Further, the describedubiquitous witness addresses the challenges associated with dataretention and data aggregation in connection with evidence gathering. Inparticular, the ubiquitous witness provides real-time data collectionusing visual fog computing. For example, when an interesting event(e.g., anomalous, unusual, rare) occurs, a snapshot of local data islocked (e.g., securely stored) by the subject device that detected theevent, thus preventing the data from being overwritten. Further, thesubject that detected the event notifies other relevant subjects (e.g.,nearby subjects in many cases) in real time to lock their respectivecounterpart data snapshots. Further, the data retention problem can beaddressed using quality of service (QoS) designations to prioritizewhich data to store versus expire (e.g., visual data versus other formsof data). Further, with visual fog computing, the data may bepreprocessed to save bandwidth for the next step of data aggregation. Inparticular, the ubiquitous witness provides automated data aggregationusing visual fog networking. For example, once data has been retainedand optionally preprocessed by the various subject devices, thecollection of data and metadata distributed across the respectivesubject devices is aggregated using visual fog networking and/orinformation-centric networking (ICN), thus allowing the respective datasnapshots to be associated together and properly stored by the devicesor nodes in the visual fog paradigm.

In this manner, the ubiquitous witness provides various advantages inconnection with evidence gathering. For example, the central or keyevidence associated with an incident is unimpeded by data retentionpolicies, as the relevant subject devices are notified in real time tocollect and lock their respective data snapshots. As another example,information-centric networking (ICN) and/or event-based data routing canbe leveraged to provide a more efficient approach for collecting,aggregating, and/or routing data. In some embodiments, for example,relevant data can be routed by location, time, triggering event, source,destination (e.g., the responsible authorities), and/or any salientattributes describing key features of the event or incident.

FIG. 55 illustrates an example use case 5500 for an automotiveubiquitous witness. The illustrated use case 5500 includes edge devices5510 a-e, fog devices 5520 a-c, and a communication network 5530. In theillustrated example, edge devices 5510 a-e are cars with onboard sensorsand/or cameras for collecting data during operation, while fog devices5520 a-c are traffic lights or other roadside units (RSUs) with sensorsand/or cameras for local or nearby data collection. Moreover,communication network 5530 may include visual fog and/orinformation-centric networking capabilities, which may be used tofacilitate real-time collection and aggregation of data from both cars5510 and RSUs 5520 using event-based data management and storagetechniques. In this manner, a ubiquitous automotive witness may beimplemented using a combination of visual fog computing (VFC) and visualfog networking or information-centric networking (ICN), as describedfurther below in connection with FIG. 56.

FIG. 56 illustrates an example dataflow 5600 for a ubiquitous witness.In some embodiments, for example, dataflow 5600 may be performed inconnection with the example automotive use case illustrated in FIG. 55.

The illustrated dataflow begins at block 5602 by determining whether anincident has been detected. In various embodiments, for example, anincident may be detected by processing sensor data using any suitableapproach, such as identifying unexpected or outstanding changes insensor data (e.g., data from internal sensors of vehicles and/or othertypes of equipment), performing event detection and recognition usingcomputer-vision and/or machine learning techniques, and so forth.

Once an incident has been detected, that will trigger local datacollection by the detecting device (block 5604) along with nearby datacollection by any surrounding devices (block 5608), and the incidentwill also be given a name (block 5610).

For example, at block 5604, the detecting device performs local datacollection, which may involve performing local analytics in order toacquire and/or generate data and/or metadata associated with theincident. The metadata, for example, may include or otherwise identifyregions of interest (ROIs), geolocation names (e.g., addresses, cities,states, zip codes, landmarks, countries), tagging or labels on the sceneof the incident derived using computer vision techniques (e.g., imageclassification or segmentation), weather, and/or any other contextual orcircumstantial information associated with the incident, among otherexamples. Further, the relevant data may be designated with ahigh-priority QoS in order to ensure that the data is retained.

At block 5606, mechanisms are then employed to inform nearby devices ofthe incident, which enables those devices to lock down their data aswell as perform any other actions that may be appropriate in theparticular circumstances and/or use case. For example, in the context ofa neighborhood watch, ZigBee and/or LTE may be used to notify nearbydevices of an incident for data collection purposes, while LTE and/ordedicated short-range communications (DSRC) may be used in the contextof automobile incidents. Regardless of the underlying wirelesscommunication infrastructure, an alert message is routed from the devicethat detected the incident to its neighbors in order to trigger theprocess of locking down the relevant data of the nearby or neighboringdevices (block 5608).

At block 5610, the incident is then given a “name” for identification,routing, and/or networking purposes. In some embodiments, for example,the incident name may be derived using an arbitrary combination ofinformation associated with the incident, such as location, time, event,type of incident, priority/importance/fatalities, image/video capturedof the event, and so forth. In this manner, the concatenation of thisdescriptive information can serve as the event name 5612 for purposes ofrequesting the underlying event data within an information-centricnetwork (ICN), as described further below.

At block 5818, for example, an information-centric network (ICN) may beused to request, route, and aggregate the relevant data (e.g., localdevice data 5614 and/or nearby device data 5616) based on the incidentname (e.g., the attributes associated with the data). In this manner,the network can then route or be queried for data associated with aparticular incident of interest. For example, evidence of theft in aneighborhood watch may be requested and subsequently directed to anearby police station 5822, while evidence of automobile speeding may berequested and subsequently directed to the department of motor vehicles(DMV) 5824 and/or an insurance company.

Moreover, the data associated with an incident may also be stored bycertain network resources 5820 in order to satisfy subsequent queriesrelating to the incident. For example, at block 5826, users may queryfor evidence associated with an incident using the various attributes inthe incident name. For example, a user might only know the approximatetime and place of an incident for purposes of querying the network, andthus the network can disseminate the query to the relevant data stores,and those with relevant data can then reply.

In this manner, a ubiquitous witness can be implemented by leveragingvisual fog computing to perform data processing and/or pre-processing atedge and/or fog nodes, followed by using visual fog networking and/orinformation-centric networking (ICN) to associate and/or aggregate thecollection of evidence for an incident (e.g., data and metadata fromvarious sources), timely route the evidence to the appropriatedestination(s), and/or store the evidence in the appropriate datastores. Further, in some embodiments, a ubiquitous witness may beimplemented within a network topology that leverages “converged node”routers, as described further below in connection with FIGS. 62-63.

FIGS. 57-60 illustrate examples of anomaly detection and eventreconstruction for a ubiquitous visual computing witness. With respectto the automotive industry, for example, vehicles currently comeequipped with an array of sensors designed to sense and record amultitude of data (e.g., speed, direction, fuel levels). These sensorsare often present internally within a vehicle as well as mountedexternally on the vehicle. Externally mounted sensors, for example, mayinclude visual/audio sensors such as cameras that are used for recordingor capturing the road, lane boundaries, surrounding vehicles orobstacles, and so forth. Moreover, with respect to the ongoingdevelopment of connected and autonomous vehicles, the range andfunctionality of such sensors is only going to increase. Similarly, thenumber of sensors deployed to instrument the roadside infrastructure isalso going to increase dramatically. An important use case for thisenormous volume of collected data is anomaly detection, such as thedetection of an unusual event or incident involving vehicles, people,and/or infrastructure. For example, proximate sensory data can beassimilated in order to reconstruct the sequence of events leading up tothe anomaly in a multi-dimensional manner. Further, when the anomaly isa vehicular accident involving damage to a person or property, this typeof reconstruction can also be used to determine the primary responsibleparties for purposes of restitution and insurance, particular in theabsence of traditional eye witnesses.

Currently, however, the data generated by the various sensors invehicles and roadside infrastructure is often isolated, as it is oftenstored in separate vendor- or application-specific clouds. There arevarious reasons for this, including but not limited to the following:(1) sensors within a single vehicle may be deployed by differentmanufacturers and their respective data may be routed to vendor-ownedclouds; (2) obtaining data from nearby vehicles is often difficult, asthe vehicles may be manufactured by different vendors that havedifferent ways of capturing and storing information, includingpotentially different proprietary formats for sensory data; and (3) theentities involved may or may not be available or traceable in the firstplace.

Accordingly, with respect to existing solutions, sensor fusion existsstrictly within each individual vehicle and is strictly siloed by eachsensor vendor. Thus, sensor fusion can only be leveraged to aggregateimage data collected from the field of view of each vehicle inisolation. Moreover, while existing video aggregation solutions cancollect streams from multiple cameras (e.g., infrastructure-basedsolutions such as video surveillance or augmented reality), thosesolutions are ineffective when the sensors are owned by multipledifferent manufacturers, their “black box” data is generallyproprietary, and there is very little cross-organization access orcoordination. Accordingly, video aggregation and stitching using camerasin roadside infrastructure is typically limited to specific functions(e.g., traffic management services, awareness of road conditions, and/orsurveillance). These respective approaches fall short in addressinganomaly detection in a globally distributed fashion, on the fly (e.g.,in real time), and from multiple parties, particularly with respect tothe fusion of data from both static and mobile entities.

Accordingly, this disclosure presents a solution for multi-dimensionalanomaly event reconstruction for smart automated systems, such asautonomous vehicles and smart cities. In particular, the describedembodiments enable multi-dimensional reconstruction of detectedanomalies, where the multi-dimensional aspect refers to the ability torecreate an event from many different perspectives using multi-modalsensory information from multiple sources. These sources can includesensors, cameras, and/or other audio/visual elements, which may residein multiple vehicles, roadside infrastructure, and/or the “black box” ofinformation required by regulation for each vehicle. The objective is tosolicit enough reconstruction data to recreate the event (which occurredat a particular point in time and space) in multiple dimensions (fromdifferent vantage points), while simultaneously scoping the solicitationwithin a bounded region of relevance.

Anomaly detection and event reconstruction is a multi-stage process thatbegins when a potential anomaly is detected. In some embodiments, forexample, an anomaly may be detected by analyzing sensor data from one ormore sources using any suitable processing techniques (e.g., computervision, machine learning, artificial neural networks). The detection andidentification of the anomaly (e.g., time, location and/or type ofanomaly) may then serve as inputs to the event reconstruction process.In some embodiments, for example, the event reconstruction process mayinvolve (1) digital witness identification, (2) data gathering, and (3)multi-dimensional event reconstruction, as described below.

1. Digital Witness Identification.

Once the anomaly is detected, the first stage of the response isidentifying the parties involved, including those involved directly inthe anomaly and those that are digital witnesses to the anomaly, both ofwhich may possess data needed to reconstruct the anomaly.

2. Data Gathering.

The second stage involves data gathering from the relevant parties thathave been identified. The data gathering stage can be implemented usingany suitable approach and/or technology, including a cloud-basedsolution that uses IP-based routing, and/or an edge-based solution thatleverages information-centric networking (ICN) or ICN-based routing,among other examples. Further, in some embodiments, a network topologyimplemented with “converged node” routers may be leveraged to facilitatethe data gathering process, as described further below in connectionwith FIGS. 62-63.

3. Multi-Dimensional Event Reconstruction.

The third stage then uses the gathered data to perform multi-dimensionalevent reconstruction. In some embodiments, for example,three-dimensional (3D) event reconstruction may be used to recreate theevent from a variety of different types of sensory data (e.g., image,audio, video), using different media-appropriate processing algorithmsto assimilate all the sensory information in a time-synchronizedfashion.

Accordingly, this disclosure presents a novel solution for generalanomaly detection and event reconstruction, which can be leveraged for avariety of use cases, including connected and autonomous vehicles thatlive within a smart transportation infrastructure. In this manner, thesensing capabilities of multiple vehicles and the surroundinginfrastructure can be leveraged for anomaly detection and eventreconstruction purposes.

FIG. 57 illustrates an example use case 5700 for automotive anomalydetection and event reconstruction. The illustrated use case 5700includes a plurality of cars 5710 driving on a road, along with multipleroadside units (RSUs) 5720 on the side of the road (e.g., trafficlights, lampposts, road signs, and/or other roadside infrastructure).The cars 5710 and RSUs 5720 are each equipped with a collection ofsensors and/or cameras for capturing data associated with theirrespective operating environments, along with communication interface(s)to facilitate communication with each other and/or other networks.

Moreover, the illustrated example portrays a snapshot in time and spaceof an automotive anomaly that involves a collision between two vehicles.The collision may be detected and recorded as an anomalous incident(e.g., with details of time and location) by any of the vehiclesinvolved in the collision (either directly involved or indirectlyinvolved as witnesses) and/or the roadside infrastructure or RSUs. Invarious embodiments, for example, an anomaly may be detected byprocessing sensor data using any suitable approach, such as identifyingunexpected or outstanding changes in sensor data (e.g., data frominternal sensors of vehicles and/or other types of equipment),performing event detection and recognition using computer-vision and/ormachine learning techniques, and so forth.

Once an anomaly has been detected, the exact sequence of events leadingup to the collision and slightly beyond can then be reconstructed, asdescribed further below. For example, FIGS. 58-60 present varioussolutions for anomaly detection and reconstruction using both InternetProtocol (IP) networks and Information-Centric Networks (ICN).

With respect to IP-based embodiments, for example, the eventreconstruction process begins by identifying all entities that may haveuseful data for the reconstruction process. In many cases, for example,it can be assumed that potentially relevant entities are those thatreside within a region of interest referred to as the “anomaly coveragearea” 5730 during a particular time window in which the anomalyoccurred. The process of identifying these entities or “witnesses” canbe triggered in multiple ways, including by vehicle(s) involved in theincident and/or nearby roadside infrastructure.

In some embodiments, for example, the process of identifying relevantentities or “witnesses” may be triggered by a vehicle that detects ananomaly, such as a vehicle directly involved in an incident or a nearbyvehicle that merely witnesses the incident. As noted above, for example,many vehicles come equipped with sensors, cameras, and some level ofautomation, and the scope and sophistication of that technology iscontinuously increasing due to the ongoing development of connected andautonomous vehicles. Accordingly, a vehicle may leverage those varioustechnologies to detect an anomalous incident or event (e.g., based on asudden shock, air bag deployment, shock of the impact with anothervehicle, unusual audio or video, and so forth). On detection of theanomalous event, the vehicle system triggers an alert and generates anautomatic push request to send all sensor logs (including camera videostreams) within a time window that extends pre- and post-incident to thevehicle's cloud systems (e.g., clouds of the vehicle manufacturer,insurer, municipal authorities, and so forth). The cloud, upon receiptof data associated with the anomalous event, may then employ ananalytics engine to perform a search of the visual/sensory data usingtimestamp information to find license plates and other identifyinginformation of the surrounding vehicles and/or infrastructure. Thelicense plate information may then be mapped to the correspondingvehicle owners using a vehicle database (e.g., a publicly availabledatabase maintained by the Department of Motor Vehicles (DMV) in theU.S. or the equivalent in other countries). The cloud engine then sendsout a request for information to the identified vehicles and theirowners to reconstruct the event using an application server.Alternatively, the vehicles involved in the incident can process theirown logs within their own local analytics engine even before the upload,and then through the local analytics engine, identify other vehicles andwitnesses that were within the anomaly coverage area 5730.

Alternatively, the process of identifying relevant entities or“witnesses” may be triggered by roadside infrastructure located withinthe anomaly coverage area 5730. For example, roadside infrastructure mayinclude various types of roadside units (RSUs) with edge and fogcomputing capabilities (e.g., storage, processing,communication/routing, sensors/cameras), such as traffic lights, streetlights, lampposts, road signs, and so forth. In this manner, roadsideinfrastructure within the anomaly coverage area 5730 may detect,witness, or otherwise be alerted to an anomalous incident, and thus maytrigger an alert or response to the incident. For example, theinfrastructure equipment may send sensory data (e.g., video streamingfeeds) from a time window that extends pre- and post-incident to anappropriate authority and/or cloud destination (e.g., the roadside unit(RSU) infrastructure cloud) to provide proof of witness. In this manner,the event reconstruction process is triggered by the roadsideinfrastructure, as described further below in connection with FIG. 58.

FIG. 58 illustrates a process flow 5800 for anomaly detection andreconstruction orchestrated by roadside unit (RSU) infrastructure overIP networks. In particular, the RSU local cloud performs analytics usingobject recognition techniques and generates an event trigger to its ownRSU cloud (block 5802), while simultaneously uploading its content tothat cloud (block 5804). In parallel, the other entities involved (e.g.,vehicles) also upload their data to their own local clouds (block 5806).The RSU cloud performs further analytics, obtains additional informationon the entities involved in the anomaly, and sends queries to the cloudsof those entities to gather their data (block 5808). Those clouds thenrespond with corresponding data that is responsive to the anomaly searchquery (e.g., based on coverage area, time delta) (block 5810). Further,as more data is collected and additional processing is performed,additional entities with potentially relevant data may be identified,and those entities may be queried for their respective data in a similarmanner. The process may continue in this manner until the entire datasetassociated with the anomalous incident has been collected from allentities that have been identified as relevant.

As an example, once the data solicitation requests have been sent out,the responsive data may subsequently be aggregated at the entity thatinitially triggered the process, such as the RSU cloud or its associatedmunicipal authority, the vehicle manufacturer, an insurance provider,and so forth. Further, in some cases, the same anomaly may bereconstructed by multiple different participants, such as the municipalauthorities that own the RSUs (e.g., to improve traffic safetymeasures), the vehicle manufacturers (e.g., to improve their connectedvehicle technology), and the insurance providers (e.g., to understandsocietal accident patterns), largely using the same process describedabove. After the data is gathered, it must then be stitched together tore-create the event. In various embodiments, for example, eventreconstruction may be performed by consolidating sensor data frommultiple sources and perspectives into a multi-dimensionalrepresentation using any suitable processing techniques, such as sensorfusion, computer vision, artificial neural networks, machine learning,and so forth.

In some embodiments, the various clouds may provide applicationprogramming interfaces (APIs) that allow other clouds or entities toquery for and receive data in a format that can be parsed and decoded bythe recipients. Further, each individual database within each individualcloud may be responsible for determining the legitimacy of the entitiesthat request or query for data, including whether they have permissionto receive the responsive data. Similarly, the receiver of the data maybe responsible for determining the authenticity of data received inresponse to its query. In various embodiments, these types of safeguardscan be implemented using an offline process, or they can take place inreal-time if the requisite systems and authorizations for data accesshave been properly deployed and configured.

FIGS. 59-60 illustrates a process flow for anomaly detection andreconstruction over information-centric networks (ICNs). For example, inthe illustrated process flow, it is assumed that the participatingentities shown in the use case of FIG. 57 (e.g., vehicles, surroundinginfrastructure, and/or any other bystanders or witnesses within theanomaly coverage area) are part of an ICN-enabled network. As discussedfurther below, there are two important differences between ICN and IPnetworks that can be exploited to improve operational efficiency in thiscontext.

First, an ICN network is capable of routing data by name (which is oftena series of attributes related to the data, such as its purpose, owner,location, and/or other contextual information) rather than by IPaddress, which enables location-independent routing. This capability canbe leveraged through the use of a “fuzzy request,” which requestsanomaly-related data based on a name that includes the time and locationof the anomaly, as well as a delta of uncertainty, among other potentialcharacteristics or attributes. In this manner, the fuzzy request acts asa query to the network itself, but without having to know the identitiesor IP addresses of the entities that detected the anomaly. Further, thedelta of uncertainty allows responses from any entities that werelocated within a scoped physical region of interest—and that collectedqualifying data of interest—at a time when the anomaly occurred plus orminus a threshold margin of error before and after the anomalous event.

Second, an ICN network offers caching natively at the routing layer,meaning as data passes through a router it may optionally be cached forlater usage (e.g., when the source of the data is unavailable due tomobility, interference, disconnectivity, an energy-saving sleep mode,and so forth). This has the side effect of making data available inmultiple locations and potentially much closer to the requesters, whichsaves precious and often limited network resources. As a result, when afuzzy request is solicited, any witnesses or nodes with data that wascollected within the approximate time and location of the anomaly mayrespond to the fuzzy request, regardless of whether the data was createdor merely cached at that node.

The entities that have the capability to capture, create, process and/orstore sensory data and make it available in a form that can be shared atthe network routing layer are known as the “producers” or “publishers”in an ICN network, while the entities that request information are knownas “consumers” or “subscribers.” The physical network itself is formedthrough the interconnection of the underlying participants using certainconnectivity solution(s) (e.g., LTE, DSRC, Wi-Fi, 5G), and thus thenetwork continuously changes as its participants join and leave (e.g.,as vehicles connect to and disconnect from base stations while movingfrom one cell to another).

This framework enables distributed storage of anomaly information acrossvehicles and roadside infrastructure in the anomaly coverage area, whilealso allowing “subscriber” nodes (e.g., the DMV, insurance companyinvestigation systems, vehicle manufacturer post-accident services) topull together all pieces of the stored view of the anomaly andreconstruct the scene. Given that ICN does not require the underlyingparticipants to be specifically known or identifiable, but insteadmerely requires the name and/or attributes of relevant data to be known,the process of gathering anomaly data from numerous sources is much morestraightforward. Scene reconstruction can then take place in a cascadedand cooperative manner, as described further below.

FIG. 59 illustrates the overall system-level process flow 5900 foranomaly detection and reconstruction via an ICN network, while FIG. 60illustrates the process flow 6000 at an individual node within the ICNnetwork. Turning to FIG. 59, the process flow 5900 begins when one ofthe entities (either a static infrastructure element or a mobile elementsuch as a vehicle) detects an anomaly, such as a collision. Theillustrated example assumes the anomaly is detected by a roadside unit(RSU), which sends an alert to trigger the reconstruction process.

For example, upon detecting the anomaly, the RSU sends a “scopedinterest” packet over the ICN network (block 5902) using multicast inorder to allow the packet to be heard and/or received by the respectiveentities that are within the coverage range of the network. In typicalICN networks, for example, a subscriber sends an “interest packet” thatcontains the precise name of the desired content or data. In this case,however, because the subscriber does not know the exact name of thecontent, the scoped interest packet merely identifies certain attributesof the desired content. Thus, the structure of a scoped interest packetdiffers from traditional ICN interest packets, as a scoped interestpacket is essentially a “fuzzy” request for data that satisfies certaincriteria rather than a request for data with a precise name. In someembodiments, for example, a scoped interest packet may request databased on an approximate location in space and time, such as datacaptured within certain deltas relative to a reference location x,y,z(RefLoc) and a reference time t (RefTime).

The naming convention for such an anomaly re-construction process isdesigned and implemented a-priori to facilitate the search. For example,each participating publisher follows the same naming convention suchthat the object names of the sensory data being recorded are namedconsistently, such as using the following format:

-   -   GeographicalLocation/Date/Timestamp/EntityName.        The geographical location could be a standardized format that is        similar to the naming mechanism for map tiles used to construct        vehicular maps. The date and timestamp reflect the local date        and time for the particular geographical location. The entity        name could reflect a unique identity for a vehicle or the        infrastructure equipment. The query contains the geographical        location, date, and timestamp in the same format as the naming        convention to facilitate an efficient search.

In some embodiments, a scoped interest packet may also identify and/orinclude a “function” for each node to apply to any data collected inresponse to the interest packet, such as a particular processingfunction for aggregating and/or compressing responsive data received atthe intermediate hops before it reaches the original subscriber, thusimproving network efficiency.

The scoped interest packet is received by multiple vehicles or nodes(blocks 5904 and 5906), and each node searches for responsive data andmay also forward the packet along to other nodes (blocks 5908 and 5910).

The process flow of an individual node is further illustrated anddescribed in connection with FIG. 60. For example, turning to FIG. 60,after the RSU has sent a scoped interest packet (block 6002) that isreceived by a vehicle or other node (block 6004), the node checks to seeif another entity has issued a similar interest packet that has beenbuffered in the node's pending interest packet table (block 6006). If asimilar interest packet has already been received, that means the nodehas already seen this request, and thus the node deletes the currentinterest packet (block 6008). If a similar interest packet has not beenreceived, the node has not sent this request, and thus the node performslongest prefix matching for the named content within its cache to searchfor responsive content that matches the query parameters (block 6010).If responsive content is identified, the node then saves the content(block 6014).

However, unlike a conventional ICN where the transaction ends once anode provides matching content in response to an interest packet, herethe node forwards the interest packet to other potentially relevantnodes (block 6014) and also stores the packet in its pending interesttable to avoid processing duplicative interest packets for the samequery or incident. In order to bound the region where the interestpacket propagates, a “scoped” region of interest is defined in theinterest packet, such that the interest packet continues to propagatewithin the scoped region until the requisite “proximity” is exceeded. Insome cases, for example, the scoped region may be defined as a certainradius around the anomalous event, such as a radius that corresponds tothe maximum range or visibility of cameras that could potentiallycapture the event. If a particular node does not find any matchingcontent for a given “scoped interest” packet, that is an indication thatthe query has reached its geographical boundary, and thus the node doesnot forward the packet any further (block 6012).

As responsive data packets are received by the various nodes and endpoints in response to the forwarded scoped interest packet, each nodemay wait for a certain timer T to expire in order to gather allresponses before sending its own response to the scoped interest packet(block 6016). In this manner, the ultimate response contains acomprehensive collection of data from many content providers rather thanonly a single content provider. This approach enables a many-to-one typeof transaction at the network layer, where a single request associatedwith a scoped interest packet can be satisfied by multiple providers whoin turn may forward the scoped interest packet along, although whethereach provider also accumulates responses from multiple providers may bedependent on the type of query and depth of the network. For example,given that many responses may be received at the intermediate nodes, thenodes may choose to aggregate and/or filter the received responsesbefore sending them along with their own response (block 6018).

FIG. 61 illustrates a flowchart 6100 for an example embodiment of aubiquitous visual computing witness. In some embodiments, for example,flowchart 6100 may be implemented using the visual computingarchitecture and functionality described throughout this disclosure.

The flowchart begins at block 6102 by accessing sensor data captured byone or more sensors of a first device. The first device, for example,may be a processing device with one or more processors, sensors, and/orcommunication interfaces. The sensors can include any type of deviceused for capturing data associated with a surrounding or operatingenvironment, such as vision sensors for generating visualrepresentations of a surrounding environment (e.g., cameras, depthsensors, ultraviolet (UV) sensors, laser rangefinders (e.g., lightdetection and ranging (LIDAR)), infrared (IR) sensors,electro-optical/infrared (EO/IR) sensors), internal sensors of vehiclesand other types of equipment, and so forth. In some embodiments, forexample, the first device may be associated with a vehicle and thesensors may include a combination of vision sensors and internalmechanical sensors. Alternatively, the first device may be associatedwith a surveillance system and the sensors may include one or morevision sensors.

The flowchart then proceeds to block 6104 to determine that an incidentoccurred within the vicinity of the first device. In some embodiments,for example, the incident may be detected based on an analysis of thesensor data captured by the sensors of the first device. For example, anincident may be detected by processing sensor data using any suitableapproach, such as identifying unexpected or outstanding changes insensor data (e.g., data from internal sensors of vehicles and/or othertypes of equipment), performing event detection and recognition usingcomputer-vision and/or machine learning techniques, and so forth. Insome embodiments, for example, an anomaly may be identified duringanalysis of the sensor data, and it may be determined that the anomalyis indicative of a particular incident or event. For example, duringsteady-state operation, sensor signals may be monitored and/or recordedto establish a baseline, and an anomaly may be identified when thesensor signals deviate from the baseline, which may be determined usingstatistical analysis, thresholds, rates, and so forth. Alternatively, oradditionally, data from visual sensors may be analyzed using imageand/or video processing techniques to identify an incident and/or eventcaptured in the visual data (e.g., using feature recognition, imageclassification, artificial intelligence, machine learning, artificialneural networks, and so forth). Further, in some embodiments, detectionof an incident may be triggered based on the cumulative detection ofmultiple anomalies, incidents, and/or events over a period of time.

Alternatively, the first device may be notified of the incident byanother device. For example, in some embodiments, the first device mayreceive a notification associated with the incident over aninformation-centric network (ICN), where the notification comprises arequest for data associated with the incident, and where the request fordata comprises an indication of a plurality of attributes associatedwith the incident, which the first device can use to identify relevantdata associated with the incident.

The flowchart then proceeds to block 6106 to identify and preserve dataassociated with the incident. In particular, the sensor data captured bythe first device may be analyzed in order to identify relevant sensordata that is associated with the incident. In some cases, for example,sensor data captured by the first device around the approximate time andlocation of the incident may be deemed relevant to the incident.Accordingly, the relevant sensor data may be preserved, such as bydesignating it with a high priority and/or quality of service (QoS)designation, and storing it on a suitable memory or storage device.Alternatively, in some embodiments, a snapshot of all available sensordata may be preserved in response to an incident, with differentdesignations for the most relevant data versus the remaining data. Inthis manner, the full collection of sensor data will be available forsubsequent processing and/or analysis (e.g., offline), if needed.

The flowchart then proceeds to block 6108 to notify and request datafrom other devices within the vicinity. For example, the first devicemay broadcast/multicast a notification with a request for dataassociated with the incident to other devices within the vicinity of thefirst device. In various embodiments, for example, the notification maybe transmitted over an information-centric network (ICN) and/or anIP-based network. Further, in some embodiments, the notification mayidentify various attributes associated with the incident, and/or a nameor identifier associated with the incident, which the receiving devicescan use to identify relevant data associated with the incident.

The flowchart then proceeds to block 6110 to determine whether tocontinue forwarding the request. For example, when the notification isreceived by other devices within the vicinity of the first device, eachreceiving device may determine whether it has any relevant dataassociated with the incident, as well as whether to continue forwardingthe notification. In some embodiments, for example, each receivingdevice may search for relevant data (e.g., sensor data) based on theattributes of the incident that were provided in the notification, suchas the time and/or location of the incident. Moreover, if relevant datais identified by a particular device, that device may forward thenotification and request for data to other devices within its vicinity.However, if no relevant data is identified by that device, the devicemay decline to forward the notification.

The flowchart then proceeds to block 6112 to consolidate, aggregate,and/or compress the relevant data identified and/or received by therespective devices. For example, as each device identifies its ownrelevant data and also receives relevant data from other devices that itforwarded the notification to, each device may consolidate, aggregate,and/or compress its collection of data before providing data in responseto the notification. In this manner, all relevant data from therespective devices is eventually collected and consolidated in responseto the notification associated with the incident.

The flowchart then proceeds to block 6114 to reconstruct the incidentbased on the consolidated data. In various embodiments, for example,incident reconstruction may be performed by generating amulti-dimensional representation of the incident from the consolidateddata using any suitable processing techniques, such as sensor fusion,computer vision, artificial neural networks, machine learning, and soforth.

The flowchart then proceeds to block 6116 to send the consolidated dataand/or reconstructed incident to an appropriate entity, such as a policedepartment, DMV, insurance company, vehicle manufacturer, or any otherperson or entity that needs the data.

At this point, the flowchart may be complete. In some embodiments,however, the flowchart may restart and/or certain blocks may berepeated. For example, in some embodiments, the flowchart may restart atblock 6102 to continue detecting, reconstructing, and/or reportingincidents of interest.

Converged Node

In the Internet-of-Things (IoT), there are increasing numbers of sensorsconnecting to networks. Many of them, such as cameras, are generatinghigh-volume time-sensitive data streams. Because these sensors arejoining at the very edges of a network, their data typically flows inthe direction from the edge towards the cloud, which is the reversedirection from how the network was originally provisioned. Moreover, thesize of a single data stream can be significant from a bandwidthperspective, and thus often results in latency constraints for real-timeapplications. Furthermore, many of these flows are continuous in nature.Thus, if many high-volume streams simultaneously arrive at and convergeupon the same router, which is often the case in typical hierarchicaland/or wireless network topologies, it is possible that these data flowswill not fit either in memory, local storage, and/or along the next hopin the network (which may lead to denial of service if the router isoverloaded with traffic beyond its capacity). Even when the flows arenot high-volume or continuous, if the number of flows is extremely high,the aggregated bandwidth requirements still might exceed the availableresources (both on and off platform).

These scenarios present a problem of data implosion. Current congestioncontrol techniques are inadequate, as they only partially address theproblem when there are simply too many data streams competing for routerbuffer queue resources in the network. For example, a normal layer 3(L3) router has several strategies to manage an oversized incoming datastream: (1) simply do not forward packets that do not fit (e.g., dropthem); or (2) indirectly signal the source, as well as intermediaterouters, of the mismatch in required bandwidth versus availablebandwidth (e.g., explicit congestion notification (ECN) in IP headers).At the transport layer (e.g., TCP), retransmission timeouts are used todetect congestion to reduce the flow of packets until the congestion iseased. At the application layer, a sender of data has the opportunity to(1) ask or negotiate configuration details up front before the dataexchange begins, or (2) infer from routing hints along the path how tofit the data over the route and/or transform individual data streams(e.g., by taking a data flow out of its original format and convertingit into a format that would fit the most constrained part of the paththrough the system), which can be achieved by dynamically renegotiatingwith the application how to fit the data over the network. Congestioncan also be addressed by adding more resources, such as more bandwidthusing a bigger and more expensive backbone for the aggregated flows, butthat is often a very expensive and impractical solution given theflexibility and potential scale of IoT.

The existing congestion control techniques at the application,transport, and routing layer are insufficient, as the IoT capacityproblem exists due to the increase in flows versus existing capacity,rather than a temporary congestion problem that relates solely to peakor busy hour traffic. Further, adding network capacity without incurringsignificant costs is not possible with the existing solutions.

Although congestion control algorithms seek to minimize data over-run attraditional router nodes in the network, congestion ultimately leads toa growing queue of packets, which increases end-to-end delay. When aqueue overflows, meaning there is no more room to store arriving data, arouter begins to drop packets, which may have a big impact on flows thatrequire the delivery of in-order packets or even a modicum of impact onthe delivery of flows that require reliable (but possibly out-of-order)delivery of packets, which might need to wait a roundtrip for aretransmission of any packet losses. For example, delay and/or packetloss can be highly disruptive, not to mention unacceptable for a cameramounted on a connected car whose data is meant to be archived as theblack box or ground truth for anomalous car or environmental incidents.

Accordingly, this disclosure presents various embodiments of a“converged node” that is designed to efficiently route/process/cachevisual data streams flowing in an N-to-1 manner in edge and fogcomputing systems. The converged node enables the continued transmissionof data even when there is a vast difference between the amount ofincoming data and resources available for the outgoing data. This ispossible due to the collective processing and caching ofcontextually-related streams, such as when multiple cameras captureimages from different but overlapping perspectives.

The basic idea of the converged node is to extend the functionality of atraditional L3 router to comprehend and prevent the implosion of IoTdata flows (e.g., the many-to-1 nature of data flowing upstream from adense camera deployment in a smart environment). Because multipleincoming streams are often contextually related (e.g., in space, time,and possibly other ways), converged node IoT routers offer a newstrategy: process, analyze, and transform the streams together. Forexample, a converged node effectively takes multiple incoming streamsand transforms them into a single output stream by performingtransformative compute functions on them, such as analytics, machinelearning, artificial intelligence, and so forth, which serves as a newkind of “compression.” The new emergent stream is then stored for re-useby contributing and/or nearby stakeholders.

The converged node implicates several new requirements for L3 routers inorder to service IoT deployments that have a need for supporting reversedata flows at scale (e.g., high-volume, continuous, low-latency, and/orhigh-density flows) while avoiding the data implosion problem. Forexample, with respect to a converged node, the network data flowsconverge on the node and may be combined or merged from multipleincoming streams into a single outgoing stream (while in-flight anden-route to somewhere else). The implications of this convergence offlows are that the routing, processing, and compute sub-systems can beco-designed in hardware to support low-latency handling of the data(e.g., via an internal shared data bus or shared memory). The extendedcapabilities of the L3 router, as implemented by the new converged node,are described further below.

The functionality of a converged node can be implemented in software,although additional efficiencies can be gained in a hardware solution(e.g., using accelerators and/or FPGAs). For example, a hardware versioncan employ zero-copy design, which means it would avoid copying/movingdata to each sub-system for consideration, and instead moves thefunctionality/service/operation to the data itself, subscribing to thephilosophy of “moving the compute to the data.”

The converged node provides a solution to network congestion that isscalable in a cost-efficient manner and provides greater performancethan existing solutions. For example, converged node routers can providesignificant cost and performance benefits for network operators andother entities that deploy servers for edge computing in real networks,particularly with respect to video and visual data flows. Additionally,this solution is highly applicable to contexts where the end-to-endreverse flows pass through multiple converged nodes, such as when datais organized by geographic region and thus passes up a hierarchical ormulti-tiered topology (e.g., layered administrative domains or clouds),which is often the case for video surveillance, energy monitoring, andhealthcare use cases, among other examples.

The converged node also provides benefits relating to time-sensitivecapabilities, such as the utility of high-resolution timestamps (e.g.,both to meet time-constrained delivery and time-sensitive coordinationacross multiple streams), implementing time coordinated compute (TCC)capabilities, and so forth.

As noted above, a converged node can be implemented by extending thefunctionality of a traditional router, such as an L3 router. The processflow within this extended “converged node” router may be as follows: (1)comprehend and manage the serious data implosion problem for IoT edgeand fog systems; (2) process multiple contextually-related streamssimultaneously; (3) look beyond packet headers to analyze if and how astream is interesting or notable; (4) look beyond packet headers toanalyze if and how the streams are related and might be “compressed”, inthe broader sense of the term; (5) identify a functional strategy toemerge with a single new stream going forward, which may employdifferent functions for different scenarios, necessitating the abilityto dynamically request and fetch functions/services/methods; (6) cachethe new stream for re-use by contextually-related stakeholders,particularly those that are mobile, wireless, low-power, and/orproximate, for greater resource efficiency; (7) route the new stream inthe reverse direction, which is where it was headed; (8) provide theoption to route the new stream in other directions, e.g., within a localedge cloud and/or across neighboring clouds; (9) co-design the routing,computing and caching sub-systems to minimize time delay on platform;(10) employ zero-copy HW design techniques to implement efficienthand-off of data between sub-systems; and (11) leveragetime-synchronization capabilities in the platform to synchronize acrossmultiple data streams, in preparation for the analysis/transformationphase of the N-to-1 process.

There are various ways in which streams might be considered to becontextually related to each other. For example, in some embodiments, abroad correlation between the name of the content and different streamsmay be used. In an ICN context, all the streams that respond to aspecific ICN Interest packet asking for data with a particular content“name” are considered contextually-related. The system could re-use theentries in the Pending Interest Table (PIT) as the entries in adirectory for “contextually-related” groups. In a non-ICN context, thesystem still can leverage the name of the content or name-likeattributes to organize streams into contextually-related groups, such asthe URL/URI of the content, or the transport packet header tuples (e.g.,sender and receiver addresses and port numbers), or the streamsoriginating from the same subnet address (e.g., same subnet addresspre-fix). The use of name-based techniques is beneficial over usingdeep-packet inspection of the content itself, which is a highlyresource-intensive process. Alternatively, in some embodiments, in thevisual realm, separate from ICN, streams within a “region of interest”(e.g., proximity in space and time) may be organized intocontextually-related groups of packets.

In some embodiments, for example, a converged node may include thefollowing capabilities on top of traditional router functionality: (1)analyzing data in data flows beyond packet headers; (2) defining what itmeans to be contextually-related (e.g., within a geographic region ofinterest, owned by same vendor, running the same version of malwaresoftware, and so forth); (3) collectively processing Ncontextually-related incoming data flows; (4) recommending a function toperform across these flows to “compress” them before they arerouted/cached; (5) transforming the N streams into a single, new,less-resource-consuming data flow; (6) potentially caching/storing thenew stream locally, such as for request and retrieval by nearbyproximate sensors that may have contributed to the new stream and/or bythose who have an interest in the results; and (7) routing the new datastream to its next intended upstream destination, which may be thenorthern direction in which the data was originally flowing, but mayalso include a broader dissemination, such as in the East-West directionto peer clouds or in the southern direction to interested parties.

While these functions are generally described as being performed at asingle converged node in the reverse data flow path (e.g., as shown inFIG. 62), they may be encountered and repeated multiple times in acascading fashion until the data stream reaches its final archivalresting place, as might be the case in a digital surveillance systemthat supports multiple levels of N-to-1 converged data flows. Thisend-to-end data flow and the processing-caching-routing capabilitiessurrounding it may be referred to as a reverse content distributionnetwork (rCDN). The converged nodes are viewed as the extended routersalong the end-to-end path in an rCDN, as shown in FIG. 63.

The converged node differs from previous L3 router solutions in that itrequires the router to look inside the data stream beyond the packetheader but rather focus on the content “packets payload,” which is themore traditional focus of an L3 router. Additionally, the converged nodeis capable of performing its described functionality while the datastreams are in-flight versus post-facto. The converged node routerperforms an N-to-1 transformation, which may represent a range ofprocessing capabilities, including but not limited to compression,encryption, transcoding, labeling, aggregation/grouping some flows intolarger flows based on contextual commonality, sub-sampling, combination(e.g., stitching), and analytics (e.g., which broadly refers to any typeof analysis, whether it is statistical analysis, machine learning (ML),deep learning (DL) or some other form of artificial intelligence ormachine learning).

With respect to the analytics functionality of the converged node, theprocess may take the data out of its original data format and convert itinto another format. This might be the case with summarization ofphenomena within the data stream, such as object recognition and objectcounting, or with the labeling of phenomena within the data stream, tocreate a new stream of metadata that tracks the appearance ofinteresting events in the visual field of view.

A key benefit of the proposed method is that it applies to any dense IoTdeployment suffering from N-to-1 data implosion, whether or not thestreams are video/visual in nature. Furthermore, this technique couplesnicely with information-centric network architectures, although it isnot dependent on them.

There are numerous novel concepts associated with the converged node,including: comprehending and managing the serious data implosion problemfor IoT edge and fog systems; processing multiple contextually-relatedstreams simultaneously; looking beyond packet headers to analyze if andhow a stream is interesting or notable; looking beyond packet headers toanalyze if and how the streams are related and might be “compressed” (ina broader sense of the term); identifying a functional strategy toemerge with a single new stream going forward, which may employdifferent functions for different scenarios, necessitating the abilityto dynamically request and fetch functions/services/methods; caching thenew stream for re-use by contextually-related stakeholders, particularlythose that are mobile, wireless, low-power, and/or proximate, forgreater resource efficiency; routing the new stream in the reversedirection, which is where it was headed; providing the option to routethe new stream in other directions, such as within a local edge cloudand/or across neighboring clouds; co-designing the routing, computing,and caching sub-systems to minimize time delay on the platform;employing zero-copy hardware design techniques to implement efficienthand-off of data between sub-systems; and leveragingtime-synchronization capabilities in the platform to synchronize acrossmultiple data streams, in preparation for the analysis/transformationphase of the N-to-1 process.

The flowcharts and block diagrams in the FIGURES illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousaspects of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder or alternative orders, depending upon the functionality involved.It will also be noted that each block of the block diagrams and/orflowchart illustration, and combinations of blocks in the block diagramsand/or flowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts, orcombinations of special purpose hardware and computer instructions.

The foregoing disclosure outlines features of several embodiments sothat those skilled in the art may better understand various aspects ofthe present disclosure. Those skilled in the art should appreciate thatthey may readily use the present disclosure as a basis for designing ormodifying other processes and structures for carrying out the samepurposes and/or achieving the same advantages of the embodimentsintroduced herein. Those skilled in the art should also realize thatsuch equivalent constructions do not depart from the spirit and scope ofthe present disclosure, and that they may make various changes,substitutions, and alterations herein without departing from the spiritand scope of the present disclosure.

All or part of any hardware element disclosed herein may readily beprovided in a system-on-a-chip (SoC), including a central processingunit (CPU) package. An SoC represents an integrated circuit (IC) thatintegrates components of a computer or other electronic system into asingle chip. The SoC may contain digital, analog, mixed-signal, andradio frequency functions, all of which may be provided on a single chipsubstrate. Other embodiments may include a multi-chip-module (MCM), witha plurality of chips located within a single electronic package andconfigured to interact closely with each other through the electronicpackage. In various other embodiments, the computing functionalitiesdisclosed herein may be implemented in one or more silicon cores inApplication Specific Integrated Circuits (ASICs), Field ProgrammableGate Arrays (FPGAs), and other semiconductor chips.

As used throughout this specification, the term “processor” or“microprocessor” should be understood to include not only a traditionalmicroprocessor (such as Intel's® industry-leading x86 and x64architectures), but also graphics processors, matrix processors, and anyASIC, FPGA, microcontroller, digital signal processor (DSP),programmable logic device, programmable logic array (PLA), microcode,instruction set, emulated or virtual machine processor, or any similar“Turing-complete” device, combination of devices, or logic elements(hardware or software) that permit the execution of instructions.

Note also that in certain embodiments, some of the components may beomitted or consolidated. In a general sense, the arrangements depictedin the figures should be understood as logical divisions, whereas aphysical architecture may include various permutations, combinations,and/or hybrids of these elements. It is imperative to note thatcountless possible design configurations can be used to achieve theoperational objectives outlined herein. Accordingly, the associatedinfrastructure has a myriad of substitute arrangements, design choices,device possibilities, hardware configurations, software implementations,and equipment options.

In a general sense, any suitably-configured processor can executeinstructions associated with data or microcode to achieve the operationsdetailed herein. Any processor disclosed herein could transform anelement or an article (for example, data) from one state or thing toanother state or thing. In another example, some activities outlinedherein may be implemented with fixed logic or programmable logic (forexample, software and/or computer instructions executed by a processor)and the elements identified herein could be some type of a programmableprocessor, programmable digital logic (for example, a field programmablegate array (FPGA), an erasable programmable read only memory (EPROM), anelectrically erasable programmable read only memory (EEPROM)), an ASICthat includes digital logic, software, code, electronic instructions,flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or opticalcards, other types of machine-readable mediums suitable for storingelectronic instructions, or any suitable combination thereof.

In operation, a storage may store information in any suitable type oftangible, non-transitory storage medium (for example, random accessmemory (RAM), read only memory (ROM), field programmable gate array(FPGA), erasable programmable read only memory (EPROM), electricallyerasable programmable ROM (EEPROM), or microcode), software, hardware(for example, processor instructions or microcode), or in any othersuitable component, device, element, or object where appropriate andbased on particular needs. Furthermore, the information being tracked,sent, received, or stored in a processor could be provided in anydatabase, register, table, cache, queue, control list, or storagestructure, based on particular needs and implementations, all of whichcould be referenced in any suitable timeframe. Any of the memory orstorage elements disclosed herein should be construed as beingencompassed within the broad terms ‘memory’ and ‘storage,’ asappropriate. A non-transitory storage medium herein is expresslyintended to include any non-transitory special-purpose or programmablehardware configured to provide the disclosed operations, or to cause aprocessor to perform the disclosed operations. A non-transitory storagemedium also expressly includes a processor having stored thereonhardware-coded instructions, and optionally microcode instructions orsequences encoded in hardware, firmware, or software.

Computer program logic implementing all or part of the functionalitydescribed herein is embodied in various forms, including, but in no waylimited to, hardware description language, a source code form, acomputer executable form, machine instructions or microcode,programmable hardware, and various intermediate forms (for example,forms generated by an HDL processor, assembler, compiler, linker, orlocator). In an example, source code includes a series of computerprogram instructions implemented in various programming languages, suchas an object code, an assembly language, or a high-level language suchas OpenCL, FORTRAN, C, C++, JAVA, or HTML for use with various operatingsystems or operating environments, or in hardware description languagessuch as Spice, Verilog, and VHDL. The source code may define and usevarious data structures and communication messages. The source code maybe in a computer executable form (e.g., via an interpreter), or thesource code may be converted (e.g., via a translator, assembler, orcompiler) into a computer executable form, or converted to anintermediate form such as byte code. Where appropriate, any of theforegoing may be used to build or describe appropriate discrete orintegrated circuits, whether sequential, combinatorial, state machines,or otherwise.

In one example, any number of electrical circuits of the FIGURES may beimplemented on a board of an associated electronic device. The board canbe a general circuit board that can hold various components of theinternal electronic system of the electronic device and, further,provide connectors for other peripherals. More specifically, the boardcan provide the electrical connections by which the other components ofthe system can communicate electrically. Any suitable processor andmemory can be suitably coupled to the board based on particularconfiguration needs, processing demands, and computing designs. Othercomponents such as external storage, additional sensors, controllers foraudio/video display, and peripheral devices may be attached to the boardas plug-in cards, via cables, or integrated into the board itself. Inanother example, the electrical circuits of the FIGURES may beimplemented as stand-alone modules (e.g., a device with associatedcomponents and circuitry configured to perform a specific application orfunction) or implemented as plug-in modules into application specifichardware of electronic devices.

Note that with the numerous examples provided herein, interaction may bedescribed in terms of two, three, four, or more electrical components.However, this has been done for purposes of clarity and example only. Itshould be appreciated that the system can be consolidated orreconfigured in any suitable manner. Along similar design alternatives,any of the illustrated components, modules, and elements of the FIGURESmay be combined in various possible configurations, all of which arewithin the broad scope of this specification. In certain cases, it maybe easier to describe one or more of the functionalities of a given setof flows by only referencing a limited number of electrical elements. Itshould be appreciated that the electrical circuits of the FIGURES andits teachings are readily scalable and can accommodate a large number ofcomponents, as well as more complicated/sophisticated arrangements andconfigurations. Accordingly, the examples provided should not limit thescope or inhibit the broad teachings of the electrical circuits aspotentially applied to a myriad of other architectures.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained to one skilled in the art and it isintended that the present disclosure encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the scope of the appended claims.

Example Implementations

The following examples pertain to embodiments described throughout thisdisclosure.

One or more embodiments may include an apparatus, comprising: a memoryto store sensor data captured by one or more sensors associated with afirst device; and a processor comprising circuitry to: access the sensordata captured by the one or more sensors associated with the firstdevice; determine that an incident occurred within a vicinity of thefirst device; identify a first collection of sensor data associated withthe incident, wherein the first collection of sensor data is identifiedfrom the sensor data captured by the one or more sensors; preserve, onthe memory, the first collection of sensor data associated with theincident; and notify one or more second devices of the incident, whereinthe one or more second devices are located within the vicinity of thefirst device.

In one example embodiment of an apparatus, the circuitry to determinethat the incident occurred within the vicinity of the first device isfurther to: analyze the sensor data captured by the one or more sensors;identify an anomaly associated with the sensor data; and detect theincident based on the anomaly associated with the sensor data.

In one example embodiment of an apparatus, the circuitry is further to:receive a notification associated with the incident over aninformation-centric network, wherein the notification comprises arequest for data associated with the incident, and wherein the requestfor data comprises an indication of a plurality of attributes associatedwith the incident; and determine whether the sensor data captured by theone or more sensors corresponds to the plurality of attributesassociated with the incident.

In one example embodiment of an apparatus, the plurality of attributesassociated with the incident comprises a time and a location of theincident.

In one example embodiment of an apparatus, the circuitry is further togenerate an identifier for the incident, wherein the identifier isgenerated based on one or more attributes associated with the incident.

In one example embodiment of an apparatus, the circuitry to notify theone or more second devices of the incident is further to: broadcast anotification associated with the incident over an information-centricnetwork, wherein the notification comprises a request for dataassociated with the incident, and wherein the notification is receivedby the one or more second devices.

In one example embodiment of an apparatus, the circuitry is further to:receive one or more second collections of sensor data associated withthe incident, wherein the one or more second collections of sensor dataare received from the one or more second devices; and generate aconsolidated collection of sensor data associated with the incident,wherein the consolidated collection of sensor data is generated from thefirst collection of sensor data and the one or more second collectionsof sensor data.

In one example embodiment of an apparatus, the circuitry is further tosend the consolidated collection of sensor data to an entity associatedwith the incident.

In one example embodiment of an apparatus, the circuitry is further togenerate a reconstructed representation of the incident based on theconsolidated collection of sensor data.

In one example embodiment of an apparatus, the incident comprises anautomobile accident, and wherein the first device is associated with: avehicle involved in the automobile accident; or roadside infrastructurelocated near the automobile accident.

In one example embodiment of an apparatus, the first device isassociated with a surveillance system, and wherein the one or moresensors comprise one or more cameras.

One or more embodiments may include a system, comprising: a plurality ofsensors to capture sensor data associated with an operating environmentof a first device; a communication interface to communicate with one ormore second devices; and a processor to: determine that an incidentoccurred within a vicinity of the first device; identify a firstcollection of sensor data associated with the incident, wherein thefirst collection of sensor data is identified from the sensor datacaptured by the plurality of sensors; preserve the first collection ofsensor data associated with the incident; and notify the one or moresecond devices of the incident, wherein the one or more second devicesare located within the vicinity of the first device.

In one example embodiment of a system, the processor to determine thatthe incident occurred within the vicinity of the first device is furtherto detect the incident based on an analysis of the sensor data capturedby the plurality of sensors.

In one example embodiment of a system, the processor is further to:receive a notification associated with the incident over aninformation-centric network, wherein the notification comprises arequest for data associated with the incident, and wherein the requestfor data comprises an indication of a plurality of attributes associatedwith the incident; and determine whether the sensor data captured by theplurality of sensors corresponds to the plurality of attributesassociated with the incident.

In one example embodiment of a system, the processor to notify the oneor more second devices of the incident is further to: broadcast anotification associated with the incident over an information-centricnetwork, wherein the notification comprises a request for dataassociated with the incident, and wherein the notification is receivedby the one or more second devices.

In one example embodiment of a system, the processor is further to:receive one or more second collections of sensor data associated withthe incident, wherein the one or more second collections of sensor dataare received from the one or more second devices; and generate aconsolidated collection of sensor data associated with the incident,wherein the consolidated collection of sensor data is generated from thefirst collection of sensor data and the one or more second collectionsof sensor data.

In one example embodiment of a system, the processor is further to sendthe consolidated collection of sensor data to an entity associated withthe incident.

In one example embodiment of a system, the processor is further togenerate a reconstructed representation of the incident based on theconsolidated collection of sensor data.

One or more embodiments may include at least one machine accessiblestorage medium having instructions stored thereon, wherein theinstructions, when executed on a machine, cause the machine to: accesssensor data captured by one or more sensors associated with a firstdevice; detect an incident that occurs within a vicinity of the firstdevice, wherein the incident is detected based on an analysis of thesensor data; identify a first collection of sensor data associated withthe incident, wherein the first collection of sensor data is identifiedfrom the sensor data captured by the one or more sensors; preserve thefirst collection of sensor data associated with the incident; and notifyone or more second devices of the incident, wherein the one or moresecond devices are located within the vicinity of the first device.

In one example embodiment of a storage medium, the instructions furthercause the machine to: receive a notification associated with theincident over an information-centric network, wherein the notificationcomprises a request for data associated with the incident, and whereinthe request for data comprises an indication of a plurality ofattributes associated with the incident; and determine whether thesensor data captured by the one or more sensors corresponds to theplurality of attributes associated with the incident.

In one example embodiment of a storage medium, the instructions furthercause the machine to: broadcast a notification associated with theincident over an information-centric network, wherein the notificationcomprises a request for data associated with the incident, and whereinthe notification is received by the one or more second devices; receiveone or more second collections of sensor data associated with theincident, wherein the one or more second collections of sensor data arereceived from the one or more second devices; generate a consolidatedcollection of sensor data associated with the incident, wherein theconsolidated collection of sensor data is generated from the firstcollection of sensor data and the one or more second collections ofsensor data; and send the consolidated collection of sensor data to anentity associated with the incident.

In one example embodiment of a storage medium, the instructions furthercause the machine to generate a reconstructed representation of theincident based on the consolidated collection of sensor data.

One or more embodiments may include a method, comprising: accessingsensor data captured by one or more sensors associated with a firstdevice; detecting an incident that occurs within a vicinity of the firstdevice, wherein the incident is detected based on an analysis of thesensor data; identifying a first collection of sensor data associatedwith the incident, wherein the first collection of sensor data isidentified from the sensor data captured by the one or more sensors;preserving the first collection of sensor data associated with theincident; and notifying one or more second devices of the incident,wherein the one or more second devices are located within the vicinityof the first device.

In one example embodiment of a method, the method further comprises:receiving a notification associated with the incident over aninformation-centric network, wherein the notification comprises arequest for data associated with the incident, and wherein the requestfor data comprises an indication of a plurality of attributes associatedwith the incident; and determining whether the sensor data captured bythe one or more sensors corresponds to the plurality of attributesassociated with the incident.

In one example embodiment of a method, the method further comprises:broadcasting a notification associated with the incident over aninformation-centric network, wherein the notification comprises arequest for data associated with the incident, and wherein thenotification is received by the one or more second devices; receivingone or more second collections of sensor data associated with theincident, wherein the one or more second collections of sensor data arereceived from the one or more second devices; generating a consolidatedcollection of sensor data associated with the incident, wherein theconsolidated collection of sensor data is generated from the firstcollection of sensor data and the one or more second collections ofsensor data; and sending the consolidated collection of sensor data toan entity associated with the incident.

What is claimed is:
 1. A computing device for reconstructing anomalousevents from sensor data captured by edge devices, comprising:communication circuitry to communicate over a network; and processingcircuitry to: determine that an anomalous event occurred; send, via thecommunication circuitry, a request for sensor data captured within aproximity of the anomalous event; receive, via the communicationcircuitry, multimodal sensor data from a plurality of edge deviceswithin the proximity of the anomalous event, wherein the multimodalsensor data is captured by a plurality of types of sensors from aplurality of perspectives; and generate, based on the multimodal sensordata, a multidimensional representation of the anomalous event, whereinthe multidimensional representation of the anomalous event is torepresent the anomalous event from the plurality of perspectivescaptured by the plurality of types of sensors.
 2. The computing deviceof claim 1, wherein the processing circuitry to determine that theanomalous event occurred is further to: receive, via the communicationcircuitry, an indication that the anomalous event occurred from a firstedge device within the proximity of the anomalous event.
 3. Thecomputing device of claim 1, wherein the processing circuitry todetermine that the anomalous event occurred is further to: obtain afirst set of sensor data captured within the proximity of the anomalousevent; and detect the anomalous event based on an analysis of the firstset of sensor data.
 4. The computing device of claim 3, wherein theprocessing circuitry to obtain the first set of sensor data capturedwithin the proximity of the anomalous event is further to: receive, viathe communication circuitry, the first set of sensor data from a firstedge device, wherein the first set of sensor data is captured within theproximity of the anomalous event by the first edge device.
 5. Thecomputing device of claim 3, wherein: the computing device furthercomprises one or more sensors to capture the first set of sensor datawithin the proximity of the anomalous event; and the processingcircuitry to obtain the first set of sensor data captured within theproximity of the anomalous event is further to: obtain the first set ofsensor data from the one or more sensors.
 6. The computing device ofclaim 3, wherein the processing circuitry to send, via the communicationcircuitry, the request for sensor data captured within the proximity ofthe anomalous event is further to: identify, based on the first set ofsensor data, the plurality of edge devices within the proximity of theanomalous event; and send, via the communication circuitry, the requestfor sensor data to the plurality of edge devices within the proximity ofthe anomalous event.
 7. The computing device of claim 1, wherein theprocessing circuitry to send, via the communication circuitry, therequest for sensor data captured within the proximity of the anomalousevent is further to: broadcast the request for sensor data over aninformation-centric network, wherein the request for sensor data is toindicate a plurality of attributes associated with the anomalous event,wherein the plurality of attributes comprise a time window and ageographical region of interest corresponding to the anomalous event. 8.The computing device of claim 1, wherein the processing circuitry togenerate, based on the multimodal sensor data, the multidimensionalrepresentation of the anomalous event is further to: perform sensorfusion on the multimodal sensor data to generate the multidimensionalrepresentation of the anomalous event from the plurality of perspectivescaptured by the plurality of types of sensors.
 9. The computing deviceof claim 1, wherein the processing circuitry is further to: receive, viathe communication circuitry, a request for information associated withthe anomalous event; and send, via the communication circuitry and basedon the request for information associated with the anomalous event, atleast one of: the multidimensional representation of the anomalousevent; or the plurality of sets of sensor data.
 10. The computing deviceof claim 1, wherein: the anomalous event is associated with anautomobile accident; and the computing device is associated with: avehicle within the proximity of the automobile accident; or roadsideinfrastructure within the proximity of the automobile accident.
 11. Thecomputing device of claim 1, wherein: the anomalous event is associatedwith criminal activity; and the computing device is associated with asurveillance system within the proximity of the criminal activity. 12.The computing device of claim 1, wherein the proximity of the anomalousevent comprises a geographical proximity and a temporal proximity. 13.At least one non-transitory machine accessible storage medium havinginstructions stored thereon, wherein the instructions, when executed onprocessing circuitry, cause the processing circuitry to: determine thatan anomalous event occurred; send, via communication circuitry forcommunicating over a network, a request for sensor data captured withina proximity of the anomalous event; receive, via the communicationcircuitry, multimodal sensor data from a plurality of edge deviceswithin the proximity of the anomalous event, wherein the multimodalsensor data is captured by a plurality of types of sensors from aplurality of perspectives; and generate, based on the multimodal sensordata, a multidimensional representation of the anomalous event, whereinthe multidimensional representation of the anomalous event is torepresent the anomalous event from the plurality of perspectivescaptured by the plurality of types of sensors.
 14. The storage medium ofclaim 13, wherein the instructions that cause the processing circuitryto determine that the anomalous event occurred further cause theprocessing circuitry to: obtain a first set of sensor data capturedwithin the proximity of the anomalous event; and detect the anomalousevent based on an analysis of the first set of sensor data.
 15. Thestorage medium of claim 14, wherein the instructions that cause theprocessing circuitry to obtain the first set of sensor data capturedwithin the proximity of the anomalous event further cause the processingcircuitry to: obtain the first set of sensor data from one or moresensors; or receive, via the communication circuitry, the first set ofsensor data from a first edge device, wherein the first set of sensordata is captured within the proximity of the anomalous event by thefirst edge device.
 16. The storage medium of claim 14, wherein theinstructions that cause the processing circuitry to send, via thecommunication circuitry, the request for sensor data captured within theproximity of the anomalous event further cause the processing circuitryto: identify, based on the first set of sensor data, the plurality ofedge devices within the proximity of the anomalous event; and send, viathe communication circuitry, the request for sensor data to theplurality of edge devices within the proximity of the anomalous event.17. The storage medium of claim 13, wherein the instructions that causethe processing circuitry to send, via the communication circuitry, therequest for sensor data captured within the proximity of the anomalousevent further cause the processing circuitry to: broadcast the requestfor sensor data over an information-centric network, wherein the requestfor sensor data is to indicate a plurality of attributes associated withthe anomalous event, wherein the plurality of attributes comprise a timewindow and a geographical region of interest corresponding to theanomalous event.
 18. The storage medium of claim 13, wherein theinstructions that cause the processing circuitry to generate, based onthe multimodal sensor data, the multidimensional representation of theanomalous event further cause the processing circuitry to: performsensor fusion on the multimodal sensor data to generate themultidimensional representation of the anomalous event from theplurality of perspectives captured by the plurality of types of sensors.19. The storage medium of claim 13, wherein the instructions furthercause the processing circuitry to: receive, via the communicationcircuitry, a request for information associated with the anomalousevent; and send, via the communication circuitry and based on therequest for information associated with the anomalous event, at leastone of: the multidimensional representation of the anomalous event; orthe plurality of sets of sensor data.
 20. The storage medium of claim13, wherein: the anomalous event is associated with an automobileaccident; and the processing circuitry is associated with: a vehiclewithin the proximity of the automobile accident; or roadsideinfrastructure within the proximity of the automobile accident.
 21. Thestorage medium of claim 13, wherein: the anomalous event is associatedwith criminal activity; and the processing circuitry is associated witha surveillance system within the proximity of the criminal activity. 22.A method of reconstructing anomalous events from sensor data captured byedge devices, comprising: determining that an anomalous event occurred;sending, via communication circuitry for communicating over a network, arequest for sensor data captured within a proximity of the anomalousevent; receiving, via the communication circuitry, multimodal sensordata from a plurality of edge devices within the proximity of theanomalous event, wherein the multimodal sensor data is captured by aplurality of types of sensors from a plurality of perspectives; andgenerating, based on the multimodal sensor data, a multidimensionalrepresentation of the anomalous event, wherein the multidimensionalrepresentation of the anomalous event is to represent the anomalousevent from the plurality of perspectives captured by the plurality oftypes of sensors.
 23. The method of claim 22, wherein: determining thatthe anomalous event occurred comprises: obtaining a first set of sensordata captured within the proximity of the anomalous event; and detectingthe anomalous event based on an analysis of the first set of sensordata; and sending, via the communication circuitry, the request forsensor data captured within the proximity of the anomalous eventcomprises: identifying, based on the first set of sensor data, theplurality of edge devices within the proximity of the anomalous event;and sending, via the communication circuitry, the request for sensordata to the plurality of edge devices within the proximity of theanomalous event.
 24. The method of claim 22, wherein sending, via thecommunication circuitry, the request for sensor data captured within theproximity of the anomalous event comprises: broadcasting the request forsensor data over an information-centric network, wherein the request forsensor data is to indicate a plurality of attributes associated with theanomalous event, wherein the plurality of attributes comprise a timewindow and a geographical region of interest corresponding to theanomalous event.
 25. The method of claim 22, wherein generating, basedon the multimodal sensor data, the multidimensional representation ofthe anomalous event comprises: performing sensor fusion on themultimodal sensor data to generate the multidimensional representationof the anomalous event from the plurality of perspectives captured bythe plurality of types of sensors.
 26. The computing device of claim 1,wherein the plurality of perspectives comprises: perspectives fromdifferent camera views; or perspectives from different sensor types.